[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: selinux + livecd-creator, May 20, 2008



On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
> 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....
> > 
> > ***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:
> > 
> > /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?
> > 
> > ***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.  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...)
> > 
> > ***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?
> Can't you just mount /dev/null on /selinux/context to get this to always
> succeed?

I don't believe so, no.  Remember that /selinux/context is a
transaction-based interface where the caller writes the context and then
reads back the canonicalized context.  Omitting /selinux/context
altogether makes matchpathcon() happy, but not explicit
security_check_context() calls unless they also choose to ignore ENOENT.

-- 
Stephen Smalley
National Security Agency


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]