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