Re: I am trying to build an MLS livecd.

[Eric Paris <eparis@redhat.com>]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.