selinux + livecd-creator, May 20, 2008

[Eric Paris]

On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
> 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.

You are (once again) correct.  Should be a lot easier to lie to  :)

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

I remember the performance question, just not how it ended.  Thanks for
the refresh.
> 
> > 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?

At this point no.  A large portion of the files are going to be laid
down by rpm long before the selinux-policy rpm is installed in the
chroot (for whatever reason selinux-policy-targeted tends to be in the
last 5 or so rpms installed in every livecd creation I do), so we can't
get labels for rpm to use for the vast majority of the files.

I think the only valid user of this deferred mapping stuff for these
purposes is restorecon (or whatever equivalent) at the end.

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

Yes, I was just suggesting a new fstype to use in situation where we
expect these.  If you think just let it go, I'll just let it go  :)

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

dan wants me to (re)explore using /dev/null for /selinux/context    I
see that is going to cause some sort of issue in
security_canonicalize_context_raw().  I guess I'll keep poking this
monster with a stick (as of right now I'm not looking back at O_TRUNC,
so calm down Stephen.)

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

Yeah, completely changing the security model like this is rather scary.

/me goes to create /proc/sys/kernel/go_go_crazy_security_labels   so
LSPP/govt security nuts can keep their current code paths...