On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > 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. You are (once again) correct. Should be a lot easier to lie to :) > > ***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. I remember the performance question, just not how it ended. Thanks for the refresh. > > > 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? At this point no. A large portion of the files are going to be laid down by rpm long before the selinux-policy rpm is installed in the chroot (for whatever reason selinux-policy-targeted tends to be in the last 5 or so rpms installed in every livecd creation I do), so we can't get labels for rpm to use for the vast majority of the files. I think the only valid user of this deferred mapping stuff for these purposes is restorecon (or whatever equivalent) at the end. > > ***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. Yes, I was just suggesting a new fstype to use in situation where we expect these. If you think just let it go, I'll just let it go :) > > ***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. dan wants me to (re)explore using /dev/null for /selinux/context I see that is going to cause some sort of issue in security_canonicalize_context_raw(). I guess I'll keep poking this monster with a stick (as of right now I'm not looking back at O_TRUNC, so calm down Stephen.) > 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. Yeah, completely changing the security model like this is rather scary. /me goes to create /proc/sys/kernel/go_go_crazy_security_labels so LSPP/govt security nuts can keep their current code paths... -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
