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