On Thu, 2007-04-05 at 09:01 -0500, John E Dickerson wrote:
> Stephen Smalley wrote:
> > On Wed, 2007-04-04 at 23:27 +0200, Jan-Frode Myklebust wrote:
> >
> >> I have some sw that installs itself to /opt/whatever/libxyz.so
> >> and not /opt/whatever/lib/libxyz.so, and these library files
> >> are then getting the system_u:object_r:usr_t security context,
> >> I assume this is because the files are not on a /lib/ directory.
> >>
> >> setroubleshoot suggests running:
> >>
> >> chcon -t textrel_shlib_t /opt/whatever/libxyz.so
> >>
> >> on these files, but I'm conserned I will loose this at the
> >> next relabel.
> >>
> >> So, what's the procedure for adding own labelling rules? Can
> >> I add them directly to /etc/selinux/targeted/contexts/files/file_contexts,
> >> or should I create a separate file for these ?
> >>
> >
> > You can create local file context definitions via semanage, e.g.
> > /usr/sbin/semanage fcontext -a -t textrel_shlib_t
> > "/opt/whatever/lib.*\.so.*"
> > and then run restorecon -R on the directory to apply the context to those
> > files.
> >
> > Those definitions are stored separately (in file_contexts.local) and
> > will be preserved across updates.
> >
> Is there a way to discover what shared objects might be mislabeled other
> than simply running the application and looking for errors?
Possibly something like:
find /opt -name "*.so*" -printf "%p %Z\n" | grep -v lib_t
(i.e. find all files with .so in the name, print their path and context,
and filter out all that have lib_t already).
> I just encountered this with Matlab. I was thinking that I would just
> add the chcon command to fix the offending .so files in an RPM %post
> clause. Or I could create a file_contexts.local and do it that way, but
> this could get hairy with a dozen or more commercial applications.
semanage fcontext is preferable, whether by hand or from rpm %post, as
changes made by it will be preserved across relabels (unlike chcon).
Other option is to create a loadable policy module with your .fc
definitions, put it into the package, and install it from %post,
followed by an initial restorecon of the relevant files there to get
them into the right initial state.
> I see that /etc/selinux/targeted/contexts/files contains several
> application specific contexts, ex:
>
> /usr/(.*/)?/RealPlayer/.+\.so(\.[^/]*)* --
> system_u:object_r:textrel_shlib_t:s0
> /usr/(local/)?acroread/(.*/)?lib/[^/]*\.so(\.[^/]*)* --
> system_u:object_r:textrel_shlib_t:s0
>
> If I'm reading these correctly, these contexts are simply labeling every
> .so under a certain path with the textrel_shlib_t type. Is this the way
> to do it? It doesn't matter that files labeled with lib_t will changed
> to textrel_shlib_t as well, even when they may not need to be?
It isn't ideal from a security pov, but it shouldn't cause any harm from
a functional pov, and it avoids having to individually specify each of
the .so files for those packages and maintain such a listing. It has
been suggested that rpm could run a helper to detect .so files that
require textrels and automatically label them textrel_shlib_t, but no
one has implemented that to date.
--
Stephen Smalley
National Security Agency
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
