selinux + livecd-creator, May 20, 2008

[Stephen Smalley]

On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
> ***passwd:
> running a system with selinux enforcing/permissive (doesn't matter) and
> attempting to run livecd-creator with selinux --disabled results in
> passwd espoloding.  passwd called is_selinux_enabled() which says yes
> since /proc/mounts has an selinuxfs and the passwd calls
> selinux_enforcing() which explodes when it can't find
> a /selinux/enforce.  First discussion was to change /proc/mounts to hide
> the selinuxfs, sounds like a good plan until I realize /proc/mounts is
> actually link to /proc/self/mounts and that its getting way to complex
> tying to set up FS namespaces or whatever this is going to take.  Right
> now I'm thinking of creating a /selinux with enforce=0 in all cases
> inside the chroot, anyone see a problem with that?  (I could also work
> on fixing passwd, but i'm trying to be as 'backwards compatible' as
> possible....

Wait - you are confusing /proc/mounts and /proc/filesystems.
IIUC, you are not mounting selinuxfs within the chroot and thus it does
not appear in /proc/mounts regardless.  But it does appear
in /proc/filesystems, and that is why is_selinux_enabled() returns 1.
If you bind mount a fake file over /proc/filesystems that excludes
selinuxfs, it should cause is_selinux_enabled() to return 0.

> ***restorecon:
> do we have an interface to see what is actually in security.xattr?

No - because we don't have separate interfaces for getting/setting MAC
labels vs. getting/setting xattrs, unlike FreeBSD (where MAC labels are
a first class construct and xattrs are just a storage mechanism that may
or may not be used by the MAC module).

We had talked about the possibility of allowing processes with
CAP_MAC_ADMIN to get the raw context via getxattr in the deferred
contexts thread on selinux list.  But see my comments there.

> Making use of the wonderful new deferred selinux context patch set from
> the kernel I get beautiful message like:
> 
> /sbin/restorecon reset /sbin/dump context
> system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0
> 
> The file wasn't really "unlabeled_t" it just wasn't a valid label on the
> host machine.  Since restorecon/fixfiles runs over the same files like 3
> times during a livecd creation this gets rather annoying.  Do we have an
> interface I could use to make restorecon do the right comparison here?

Well, could we instead avoid running restorecon/fixfiles multiple times
on the same files?  And ideally just get rpm to label the files
correctly in the first place since that is why we added the kernel
patch?

> ***allow unlabeled_t fs_t:filesystem associate:
> anyone have thoughts on how we want to handle this?

I identified this in the deferred contexts patch description as needing
to be allowed, along with a policy module to do it.  See that.

>   I can probably do
> some sort of fscontext= mount magic once i figure out the right fs we
> are talking about and where the script does the mount.  But then host
> policy is going to need rules to allow everything that can associate
> with fs_t with fs_allow_unlabeled_t.  Is that hard?  I assume Dan can
> help me out there.  Does this sound like a good way to solve it?  Is
> hard coding some 'fscontext=' line into livecd-creator a good idea?
> Should I just generically allow it?  Should I make livecd-creator load a
> policy module to start off and unload it at the end?   (I don't like
> this idea since I've learned livecd-creator can be pretty fragile and
> leave things half done/half undone...)

I would tend to just allow it, either in the base policy or in a policy
module used only for livecd-creator, possibly installed from its package
if you don't want to load/remove it on each use.

> ***Invalid prefix *
> On rawhide we just dropped that stuff altogether.  Can we do the same on
> F8?  Is it actually causing a problem?  Dan, any hints on how I can make
> the system lie to you?

Do you mean just remove the security_check_context() call from
seobject.py?  Yes, I think you can just drop it.

> Needless to say, I successfully built an F8 livecd with types not known
> tot he host system on rawhide today, booted, and logged in.

That sounds favorable.

Now you just need to travel back in time before RHEL 5 was released, add
the necessary support to it, and kill the person who will stop Skynet.

> tomorrow I spend more time typing to make the policy for livecd-creator
> a bit better.....

-- 
Stephen Smalley
National Security Agency