fedora-selinux February 2008 archive
Main Archive Page > Month Archives  > fedora-selinux archives
fedora-selinux: Re: Changing policies, using enforcing=0 the fir

Re: Changing policies, using enforcing=0 the first time

From: Stephen Smalley <sds_at_nospam>
Date: Fri Feb 08 2008 - 15:39:01 GMT
To: Forrest Taylor <ftaylor@redhat.com>

On Fri, 2008-02-08 at 08:20 -0700, Forrest Taylor wrote:
> On Fri, 2008-02-08 at 09:54 -0500, Stephen Smalley wrote:
> > On Fri, 2008-02-08 at 07:42 -0700, Forrest Taylor wrote:
> > > I am running into a strange occurrence running RHEL5.1 with an updated
> > > policy (2.4.6-106.el5_1.3). By default, it runs the targeted policy. I
> > > install the mls and the strict policy and touch /.autorelabel. The
> > > first time that I boot to one of these other policies, I get a kernel
> > > panic, and I have to use enforcing=0. The strange thing is that I can
> > > then go back and forth between any policy without setting permissive
> > > mode--that is, I only have to set enforcing=0 the first time that I make
> > > a policy change, but subsequent times it is not required. Does fixfiles
> > > change something the first time that allows the relabel to work
> > > subsequent times in enforcing mode? Any thoughts?
> >
> > IIRC, RHEL5 still had separate shlib_t vs. lib_t types in the strict/mls
> > policies, which means that when you first switch from targeted, you
> > can't execute shared objects in enforcing mode until you've first
> > relabeled. targeted policy aliases them into a single type, and
> > upstream policy has done away with the distinction now as well, I
> > believe.
> >
> > So, on the first conversion, the xattrs get reset from lib_t to shlib_t,
> > then they stay that way because targeted views them as identical.
> AH! I knew it was something like that. I couldn't find the difference
> because shlib_t is a typealias to lib_t, so it always shows lib_t.
> Is there any way in the targeted policy to verify that it actually is
> shlib_t instead of lib_t? It obviously must have some difference for
> strict/mls to work.

No, the kernel canonicalizes the context to the policy's native form before returning it via getxattr. That was introduced to accomodate the transition from non-MCS/MLS to MCS/MLS, so that the kernel could auto-magically add the MCS/MLS field for files on filesystems created under the older policy (e.g. for going from RHEL4 -> RHEL5). But it also means that even if the on-disk xattr has shlib_t, the kernel will return lib_t under targeted policy due to the canonicalization. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list