[Libguestfs] selinux question and answer

[Eric Paris]

setexecon() takes an selinux context and then anything you exec after
the call will be run in the given domain.  So we suggest calling (pseudo
code).

mount /selinux
call load_policy
call setexeccon(unconfined_t)
do everything in a shell from here on out.

On Wed, 2009-08-12 at 14:40 +0100, Richard W.M. Jones wrote:
> After a bit of an epic struggle with a RHEL 5 guest, and thanks to
> Eric Paris and Dan Walsh, we seem to have hit on a recipe to make
> SELinux work, we think:
> 
> (1) The guestfsd daemon (ie. init process) must call setexeccon(3) to
> set the security context for exec'd children to "unconfined_t".

This must be done after #2 and must be done by your init daemon, not by
a chroot'd shell.  I'm not sure exactly how to make this work as
libselinux and /selinux is going to be inside the chroot.  Maybe you
want to staticly link to your own libselinux?  (I could probably work
out the black magic to cat things directly into /selinux, I think it's
easy...) 

> (3) We must run every external command (eg. "rpm") via the shell, so
> in libguestfs using "sh", never "command".

Correct.  There is another (maybe harder?) option.  If you want to still
be able to run things directly from your daemon you'll need to get the
daemon labeled unconfined_t.  This would mean calling setexecon() and
then re-execing the daemon.

> The reason for this is subtle, but to do with making sure the correct
> transitions from kernel_t (init) -> unconfined_t (shell) -> whatever
> rpm uses happen.
> 
> (4) We also need the patch (see previous email) which removes
> selinux=0 parameter.  Possibly we should use enforcing=0 however.

You will need enforcing=0.  Dan just checked and none of our shipping
policies would allow the kernel->unconfined transition we want you to
use (normal systems all go kernel->init_t->unconfined_t, and you don't
want to do all that)

> And we think that'll allow us to run rpm and have it label things
> correctly.
> 
> There is still a problem that brand new files created by the daemon
> directly won't have labels.  In a real system this is handled by
> SELinux using inotify to quickly relabel files when they are created
> [yes, really].

For only a couple of select key files (see /etc/restorecond*).  Normally
files inheriting the label of the parent directory and this is correct.


As future work instead of hard coding  system_u:object_r:unconfined_t:s0
in the setexeccon() call, we should check out what the guest defines as
the correct defualt context for the root user.  I'm sure dan could walk
you through that, but it's a future enhancement, as there very few
people who change this.

-Eric