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

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