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 -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
