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. IIUC, you are not mounting selinuxfs within the chroot and thus it does not appear in /proc/mounts regardless. But it does appear in /proc/filesystems, and that is why is_selinux_enabled() returns 1. If you bind mount a fake file over /proc/filesystems that excludes selinuxfs, it should cause is_selinux_enabled() to return 0. > ***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. > 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? > ***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. > 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...) I would tend to just allow it, either in the base policy or in a policy module used only for livecd-creator, possibly installed from its package if you don't want to load/remove it on each use. > ***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. > Needless to say, I successfully built an F8 livecd with types not known > tot he host system on rawhide today, booted, and logged in. That sounds favorable. 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. > tomorrow I spend more time typing to make the policy for livecd-creator > a bit better..... -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
