-----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@xxxxxxxxxx > 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----- -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
