Changing policies, using enforcing=0 the first time

[Forrest Taylor]

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?

Thanks,

Forrest

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency

[Forrest Taylor]

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.

Thanks,

Forrest

[Stephen Smalley]

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

[Forrest Taylor]

On Fri, 2008-02-08 at 10:39 -0500, Stephen Smalley wrote:
>  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. 
Ah, that makes sense.  Just for future reference, I can change policies
without setting permissive mode by changing the context to shlib_t on
the following:

/lib/libblkid.so*
/lib/libc.so*
/lib/libdevmapper.so*
/lib/libdl.so*
/lib/libselinux.so*
/lib/libsepol.so
/lib/libtermcap.so*
/lib/libuuid.so*

These came from the shared libraries needed for init, mount and sh.
Once those are changed, the system can get far enough through rc.sysinit
to run fixfiles.

Thanks for the help,

Forrest

[Forrest Taylor]

On Fri, 2008-02-08 at 10:42 -0700, Forrest Taylor wrote:
>  On Fri, 2008-02-08 at 10:39 -0500, Stephen Smalley wrote:
>  > 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.
>  
>  Ah, that makes sense.  Just for future reference, I can change policies
>  without setting permissive mode by changing the context to shlib_t on
>  the following:
>  
>  /lib/libblkid.so*
>  /lib/libc.so*
>  /lib/libdevmapper.so*
>  /lib/libdl.so*
>  /lib/libselinux.so*
>  /lib/libsepol.so
>  /lib/libtermcap.so*
>  /lib/libuuid.so*
>  
>  These came from the shared libraries needed for init, mount and sh.
>  Once those are changed, the system can get far enough through rc.sysinit
>  to run fixfiles. 
I hate to reply to my own post, but is there some reason that we do not
set the context on these files by default?  How do they originally get
the context--from the parent directory?  Perhaps a %post in the
selinux-policy-targeted rpm would fix it?

Thanks,

Forrest

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forrest Taylor wrote:
>  On Fri, 2008-02-08 at 10:42 -0700, Forrest Taylor wrote:
> > On Fri, 2008-02-08 at 10:39 -0500, Stephen Smalley wrote:
> >> 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.
> > Ah, that makes sense.  Just for future reference, I can change policies
> > without setting permissive mode by changing the context to shlib_t on
> > the following:
> >
> > /lib/libblkid.so*
> > /lib/libc.so*
> > /lib/libdevmapper.so*
> > /lib/libdl.so*
> > /lib/libselinux.so*
> > /lib/libsepol.so
> > /lib/libtermcap.so*
> > /lib/libuuid.so*
> >
> > These came from the shared libraries needed for init, mount and sh.
> > Once those are changed, the system can get far enough through rc.sysinit
> > to run fixfiles.
>  
>  I hate to reply to my own post, but is there some reason that we do not
>  set the context on these files by default?  How do they originally get
>  the context--from the parent directory?  Perhaps a %post in the
>  selinux-policy-targeted rpm would fix it?
>  
>  Thanks,
>  
>  Forrest 
They are set when they are installed by rpm.  The problem is that
targeted policy labels them lib_t.  And in MLS they are labeled shlib_t.
 mls policy does not allow the execution of lib_t, so when init tries to
execute the library code, it gets a denial and blows up.

In Fedora 9 and beyond all shared libraries in all policies are labeled
lib_t and confined domains are allowed execution, so in the future this
should not be a problem.
>  
>  
>  ------------------------------------------------------------------------
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkfEfuwACgkQrlYvE4MpobN/AwCg2GLC43xTjfJ4b4tVCiVzODZI
> 4xwAnR/nkRdked5hTu1nVNpcAMeKoTB4
> =PlRq
> -----END PGP SIGNATURE-----