Re: I am trying to build an MLS livecd.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2010-05-04 at 16:39 -0400, Eric Paris wrote:
> 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

So that looks correct.  What was the problem again?

-- 
Stephen Smalley
National Security Agency


--
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.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux