selinux + livecd-creator, May 20, 2008

Jeremy Katz katzj at
Tue May 20 19:35:12 UTC 2008

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

That seems pretty reasonable to me.  The contortions of trying to
get /proc/mounts right are definitely not worth it

> ***restorecon:
> do we have an interface to see what is actually in security.xattr?
> Making use of the wonderful new deferred selinux context patch set from
> the kernel I get beautiful message like:
> 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?

If not, we could dump the output to /dev/null ;-)  But, that seems a bit
less than the ideal of really checking

> ***allow unlabeled_t fs_t:filesystem associate:
> anyone have thoughts on how we want to handle this?  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.  

So I'm not clear on exactly what the cause of this is or even what it's
trying to say.  

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



More information about the fedora-selinux-list mailing list