Changing policies, using enforcing=0 the first time

[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 at 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-----