On Tue, 2010-05-04 at 15:38 -0400, Stephen Smalley wrote: > On Tue, 2010-05-04 at 14:56 -0400, Daniel J Walsh wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 05/04/2010 02:46 PM, Stephen Smalley wrote: > > > On Tue, 2010-05-04 at 14:18 -0400, Daniel J Walsh wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA1 > > >> > > >> On 05/04/2010 12:45 PM, Stephen Smalley wrote: > > >>> On Tue, 2010-05-04 at 12:34 -0400, Daniel J Walsh wrote: > > >>>> -----BEGIN PGP SIGNED MESSAGE----- > > >>>> Hash: SHA1 > > >>>> > > >>>> But for some reason. Setfiles is not writing the correct labels to the > > >>>> livecd, iff the label includes a range with a level not supported on the > > >>>> host machine. > > >>>> > > >>>> grep s15 /tmp/mls.log > > >>>> sbin/setfiles: /home matched by > > >>>> system_u:object_r:home_root_t:s0-s15:c0.c1023 > > >>>> /sbin/setfiles: /home/liveadmin matched by > > >>>> staff_u:object_r:user_home_dir_t:s0-s15:c0.c1023 > > >>>> /sbin/setfiles: /home/liveuser matched by > > >>>> privuser_u:object_r:user_home_dir_t:s0-s15:c0.c1023 > > >>>> > > >>>> When I boot the livecd these are all labeled as > > >>>> unconfined_u:object_r:TYPE:s0. > > >>>> > > >>>> Any idea why this would happen? > > >>>> > > >>>> Of course these labels are invalid, so the MLS livecd is broken. > > >>> > > >>> Does the same problem occur if the type is undefined in the host policy? > > >>> IOW, is this a problem with undefined contexts in general or specific to > > >>> the MLS field? > > >>> > > >>> What output do you get if you run setfiles with -vv? > > >>> > > >>> Could mcstransd be incorrectly mapping the range to s0? > > >>> > > >> > > >> > > >> I attached the actuall output. Problem is it takes 1/2 hour to get back > > >> to this state. > > >> > > >> mcstransd would not be running in the environment. livecd has a hacked > > >> out environment that thinks it is running SELinux in enforcing mode. > > >> > > >> /selinux is a big hack and does nothing. > > > > > > BTW, can you or Eric describe exactly what that "hacked out environment" > > > looks like and how the fake /selinux is set up? > > > > > > It seems like we could make setfiles more directly support this kind of > > > thing (via a new option) so that we don't need that fake environment at > > > all. It already uses its own SELINUX_CB_VALIDATE callback function, so > > > we can easily turn off the canonicalization of contexts when it is being > > > used on a foreign policy. > > > > > > > I think most of the hacking is to allow tools like selinux-policy to > > work correctly, without screwing up the hosts environment. > > > > I have patches coming to fix semanage which expects booleans to exist > > even if you have a different store. > > > > I think all the changes are in > > /usr/lib/python2.6/site-packages/imgcreate/creator.py > > I did the following: > # mkdir -p /altroot/proc /altroot/selinux /altroot/home/sds > # for d in /etc /lib64 /sbin /bin > do > cp -a $d /altroot/$d > done > # mount -t proc none /altroot/proc > # runcon -t livecd_t -- runcon -t setfiles_mac_t -- chroot /altroot setfiles -vv /etc/selinux/mls/contexts/files/file_contexts /home > setfiles reset /home context unconfined_u:object_r:default_t:s0->system_u:object_r:home_root_t:s0-s15:c0.c1023 > setfiles reset /home/sds context unconfined_u:object_r:default_t:s0->user_u:object_r:user_home_dir_t:s0-s15:c0.c1023 > > And I can see it on disk via: > # runcon -t livecd_t -- runcon -t setfiles_mac_t -- getfattr -n security.selinux /altroot/home/sds > getfattr: Removing leading '/' from absolute path names > # file: altroot/home/sds > security.selinux="user_u:object_r:user_home_dir_t:s0-s15:c0.c1023 > > Note that both getting and setting has to be done from setfiles_mac_t or > we'll fail the mac_admin check (unless permissive). > > dmesg shows: > SELinux: Context system_u:object_r:auditd_etc_t:s15:c0.c1023 is not valid (left unmapped). > SELinux: Context system_u:object_r:selinux_config_t:s15:c0.c1023 is not valid (left unmapped). > SELinux: Context system_u:object_r:wm_exec_t:s0 is not valid (left unmapped). > SELinux: Context system_u:object_r:home_root_t:s0-s15:c0.c1023 is not valid (left unmapped). > SELinux: Context user_u:object_r:user_home_dir_t:s0-s15:c0.c1023 is not valid (left unmapped). > > In other words, the kernel functionality for setting and getting unknown > contexts seems to be working fine, and setfiles operates correctly. As > to how livecd is messing things up, I have no idea. So I built the livecd, eventually mounted the root filesystem (what a pain, it is 3 layers deep) and checked it out: # getfattr -d -n security.selinux home/* # file: home/liveadmin security.selinux="system_u:object_r:unlabeled_t:s0 # file: home/liveuser security.selinux="system_u:object_r:unlabeled_t:s0 ********************* And if we look what the disk actually says.... # runcon -t livecd_t -- runcon -t setfiles_mac_t -- getfattr -n security.selinux home/* # file: home/liveadmin security.selinux="staff_u:object_r:user_home_dir_t:s0-s15:c0.c1023 # file: home/liveuser security.selinux="privuser_u:object_r:user_home_dir_t:s0-s15:c0.c1023 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
