***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?
Needless to say, I successfully built an F8 livecd with types not known tot he host system on rawhide today, booted, and logged in.
tomorrow I spend more time typing to make the policy for livecd-creator a bit better.....
-Eric
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.....
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....
That seems pretty reasonable to me. The contortions of trying to get /proc/mounts right are definitely not worth it
***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: 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?
If not, we could dump the output to /dev/null ;-) But, that seems a bit less than the ideal of really checking
***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.
So I'm not clear on exactly what the cause of this is or even what it's trying to say.
Needless to say, I successfully built an F8 livecd with types not known tot he host system on rawhide today, booted, and logged in.
Awesome!
Jeremy
On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
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?
FWIW, we do a final pass with restorecon/fixfiles at the end of creating the files just so that we can ensure that any files that were created as the result of a %post script or anything else which doesn't transition correctly (... perhaps because the policy doesn't know it needs to) ends up with the right final label. This is pretty confined to just the livecd-creator case, though.
Jeremy
Jeremy Katz wrote:
On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
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?
FWIW, we do a final pass with restorecon/fixfiles at the end of creating the files just so that we can ensure that any files that were created as the result of a %post script or anything else which doesn't transition correctly (... perhaps because the policy doesn't know it needs to) ends up with the right final label. This is pretty confined to just the livecd-creator case, though.
Jeremy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Can we use fixfiles restore instead of restorecon. It will output a little "*" for every 10,000 files it relabels and we don't need to see thousands of useless restorecon lines.
On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
Can we use fixfiles restore instead of restorecon. It will output a little "*" for every 10,000 files it relabels and we don't need to see thousands of useless restorecon lines.
Sure -- I can even conditionalize it being restorecon vs fixfiles based on whether you've asked for verbose output or not
Jeremy
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?
Needless to say, I successfully built an F8 livecd with types not known tot he host system on rawhide today, booted, and logged in.
tomorrow I spend more time typing to make the policy for livecd-creator a bit better.....
-Eric
On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
Jeremy Katz wrote:
On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
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?
FWIW, we do a final pass with restorecon/fixfiles at the end of creating the files just so that we can ensure that any files that were created as the result of a %post script or anything else which doesn't transition correctly (... perhaps because the policy doesn't know it needs to) ends up with the right final label. This is pretty confined to just the livecd-creator case, though.
Jeremy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Can we use fixfiles restore instead of restorecon. It will output a little "*" for every 10,000 files it relabels and we don't need to see thousands of useless restorecon lines.
Isn't that just the same as calling restorecon with -p rather than -v?
On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
***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.
In particular, see: http://marc.info/?l=selinux&m=121016477203440&w=2 http://marc.info/?l=selinux&m=121016814610025&w=2 http://marc.info/?l=selinux&m=121017332919586&w=2
It is possible, but we have to figure out how we want to handle it; we don't want every getxattr call to trigger a full capable() check along with auditing.
On Tue, 2008-05-20 at 15:43 -0400, Jeremy Katz wrote:
On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
Can we use fixfiles restore instead of restorecon. It will output a little "*" for every 10,000 files it relabels and we don't need to see thousands of useless restorecon lines.
Sure -- I can even conditionalize it being restorecon vs fixfiles based on whether you've asked for verbose output or not
I think all you need to do is omit the -v from restorecon if they didn't ask for verbose output (or use -p instead if you want some indication of progress). fixfiles is just a wrapper script around setfiles and restorecon with some additional functionality, but in this case I'm not sure it adds anything.
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.
On Tue, 2008-05-20 at 15:52 -0400, Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
***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.
In particular, see: http://marc.info/?l=selinux&m=121016477203440&w=2 http://marc.info/?l=selinux&m=121016814610025&w=2 http://marc.info/?l=selinux&m=121017332919586&w=2
It is possible, but we have to figure out how we want to handle it; we don't want every getxattr call to trigger a full capable() check along with auditing.
Patch below is un-tested and may eat your brain. But might be worth trying out. If it helps, I can take it up on selinux list.
Return the raw context value for getxattr if the caller has CAP_MAC_ADMIN and mac_admin in policy. Use non-auditing forms of the permission checks as getxattr may be called by unprivileged processes commonly and lack of permission just means that we fall back to the in-core context value, not a denial.
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 4be1563..fe4f9ad 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2765,12 +2765,24 @@ static int selinux_inode_getsecurity(const struct inode *inode, const char *name u32 size; int error; char *context = NULL; + struct task_security_struct *tsec = current->security; struct inode_security_struct *isec = inode->i_security;
if (strcmp(name, XATTR_SELINUX_SUFFIX)) return -EOPNOTSUPP;
- error = security_sid_to_context(isec->sid, &context, &size); + error = secondary_ops->capable(current, CAP_MAC_ADMIN); + if (!error) + error = avc_has_perm_noaudit(tsec->sid, tsec->sid, + SECCLASS_CAPABILITY2, + CAPABILITY2__MAC_ADMIN, + 0, + NULL); + if (!error) + error = security_sid_to_context_force(isec->sid, &context, + &size); + else + error = security_sid_to_context(isec->sid, &context, &size); if (error) return error; error = size;
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...
On Tue, 2008-05-20 at 16:08 -0400, Stephen Smalley wrote:
Use non-auditing forms of the permission checks as getxattr may be called by unprivileged processes commonly and lack of permission just means that we fall back to the in-core context value, not a denial.
If we do put this on list, lets make this an in code comment so its easy to remember in another 100 years when the next poor sap has to figure out what I am doing these days :)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 4be1563..fe4f9ad 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2765,12 +2765,24 @@ static int selinux_inode_getsecurity(const struct inode *inode, const char *name u32 size; int error; char *context = NULL;
struct task_security_struct *tsec = current->security; struct inode_security_struct *isec = inode->i_security;
if (strcmp(name, XATTR_SELINUX_SUFFIX)) return -EOPNOTSUPP;
- error = security_sid_to_context(isec->sid, &context, &size);
- error = secondary_ops->capable(current, CAP_MAC_ADMIN);
- if (!error)
error = avc_has_perm_noaudit(tsec->sid, tsec->sid,SECCLASS_CAPABILITY2,CAPABILITY2__MAC_ADMIN,0,NULL);- if (!error)
error = security_sid_to_context_force(isec->sid, &context,&size);- else
error = security_sid_to_context(isec->sid, &context, &size);
On Tue, 2008-05-20 at 16:13 -0400, Eric Paris wrote:
On Tue, 2008-05-20 at 16:08 -0400, Stephen Smalley wrote:
Use non-auditing forms of the permission checks as getxattr may be called by unprivileged processes commonly and lack of permission just means that we fall back to the in-core context value, not a denial.
If we do put this on list, lets make this an in code comment so its easy to remember in another 100 years when the next poor sap has to figure out what I am doing these days :)
Changed accordingly, and lightly tested.
---
Enable processes with CAP_MAC_ADMIN + mac_admin permission in policy to get undefined contexts on inodes. This extends the support for deferred mapping of security contexts in order to permit restorecon and similar programs to see the raw file contexts unknown to the system policy in order to check them.
---
security/selinux/hooks.c | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 4be1563..91b666a 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2754,9 +2754,7 @@ static int selinux_inode_removexattr(struct dentry *dentry, const char *name) }
/* - * Copy the in-core inode security context value to the user. If the - * getxattr() prior to this succeeded, check to see if we need to - * canonicalize the value to be finally returned to the user. + * Copy the inode security context value to the user. * * Permission check is handled by selinux_inode_getxattr hook. */ @@ -2765,12 +2763,33 @@ static int selinux_inode_getsecurity(const struct inode *inode, const char *name u32 size; int error; char *context = NULL; + struct task_security_struct *tsec = current->security; struct inode_security_struct *isec = inode->i_security;
if (strcmp(name, XATTR_SELINUX_SUFFIX)) return -EOPNOTSUPP;
- error = security_sid_to_context(isec->sid, &context, &size); + /* + * If the caller has CAP_MAC_ADMIN, then get the raw context + * value even if it is not defined by current policy; otherwise, + * use the in-core value under current policy. + * Use the non-auditing forms of the permission checks since + * getxattr may be called by unprivileged processes commonly + * and lack of permission just means that we fall back to the + * in-core context value, not a denial. + */ + error = secondary_ops->capable(current, CAP_MAC_ADMIN); + if (!error) + error = avc_has_perm_noaudit(tsec->sid, tsec->sid, + SECCLASS_CAPABILITY2, + CAPABILITY2__MAC_ADMIN, + 0, + NULL); + if (!error) + error = security_sid_to_context_force(isec->sid, &context, + &size); + else + error = security_sid_to_context(isec->sid, &context, &size); if (error) return error; error = size;
Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
Jeremy Katz wrote:
On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
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?
FWIW, we do a final pass with restorecon/fixfiles at the end of creating the files just so that we can ensure that any files that were created as the result of a %post script or anything else which doesn't transition correctly (... perhaps because the policy doesn't know it needs to) ends up with the right final label. This is pretty confined to just the livecd-creator case, though.
Jeremy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Can we use fixfiles restore instead of restorecon. It will output a little "*" for every 10,000 files it relabels and we don't need to see thousands of useless restorecon lines.
Isn't that just the same as calling restorecon with -p rather than -v?
I believe fixfiles restore only labels file systems that support labels while restorecon -R -v / Will walk all file systems. so fixfiles might be a little faster.
/usr/bin/find "$FILEPATH" \ ! ( -fstype ext2 -o -fstype ext3 -o -fstype ext4 -o -fstype ext4dev -o -fstype gfs2 -o -fstype jfs -o -fstype xfs ) -prune -o -print0 | \ ${RESTORECON} ${OUTFILES} ${FORCEFLAG} $* -0 -f - 2>&1 >> $LOGFILE
On Wed, 2008-05-21 at 10:06 -0400, Daniel J Walsh wrote:
Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote:
Jeremy Katz wrote:
On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote:
On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote:
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?
FWIW, we do a final pass with restorecon/fixfiles at the end of creating the files just so that we can ensure that any files that were created as the result of a %post script or anything else which doesn't transition correctly (... perhaps because the policy doesn't know it needs to) ends up with the right final label. This is pretty confined to just the livecd-creator case, though.
Jeremy
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Can we use fixfiles restore instead of restorecon. It will output a little "*" for every 10,000 files it relabels and we don't need to see thousands of useless restorecon lines.
Isn't that just the same as calling restorecon with -p rather than -v?
I believe fixfiles restore only labels file systems that support labels while restorecon -R -v / Will walk all file systems. so fixfiles might be a little faster.
/usr/bin/find "$FILEPATH" \ ! \( -fstype ext2 -o -fstype ext3 -o -fstype ext4 -o -fstypeext4dev -o -fstype gfs2 -o -fstype jfs -o -fstype xfs ) -prune -o -print0 | \ ${RESTORECON} ${OUTFILES} ${FORCEFLAG} $* -0 -f - 2>&1 >> $LOGFILE
I see. I'm not sure how much of a problem that is for the chroot environment, and restorecon does have the -e option for excluding parts of the tree, although it is non-optimal in implementation (ideally we could prune the tree walk itself, but I think that would require converting restorecon from using nftw to using fts, which has long been a todo item).
However, if they were to use fixfiles restore, is there a way to enable verbose mode there? /sbin/fixfiles restore -v doesn't work.
On Tue, 2008-05-20 at 16:10 -0400, Eric Paris wrote:
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 :)
I feel vindicated, I knew I saw that /proc/mounts was part of it....
init_selinuxmnt() is going to go through /proc/mounts inside the chroot and find an selinuxfs mounted back out on the host system. I think this in turn is going to cause is_selinux_enabled() to return that selinux is in fact enabled. No proof but what i know for sure is that
cat /proc/filesystems | grep -v selinux > /tmp.filesystems mount -o bind /tmp.filesystems /chroot/proc/filesystems
still caused passwd to fail because it thought selinux was enabled....
-Eric
On Tue, 2008-05-27 at 16:25 -0400, Eric Paris wrote:
On Tue, 2008-05-20 at 16:10 -0400, Eric Paris wrote:
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 :)
I feel vindicated, I knew I saw that /proc/mounts was part of it....
init_selinuxmnt() is going to go through /proc/mounts inside the chroot and find an selinuxfs mounted back out on the host system. I think this in turn is going to cause is_selinux_enabled() to return that selinux is in fact enabled. No proof but what i know for sure is that
cat /proc/filesystems | grep -v selinux > /tmp.filesystems mount -o bind /tmp.filesystems /chroot/proc/filesystems
still caused passwd to fail because it thought selinux was enabled....
Ah, yes - the optimization by Steve G changed is_selinux_enabled() to first check for a selinux_mnt previously set upon library init and uses that as indication of being enabled if present; otherwise, it falls back to checking /proc/filesystems.
Regardless, as long as you create /selinux/enforce == 0, you're ok with passwd, right?
On Tue, 2008-05-27 at 16:48 -0400, Stephen Smalley wrote:
On Tue, 2008-05-27 at 16:25 -0400, Eric Paris wrote:
On Tue, 2008-05-20 at 16:10 -0400, Eric Paris wrote:
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 :)
I feel vindicated, I knew I saw that /proc/mounts was part of it....
init_selinuxmnt() is going to go through /proc/mounts inside the chroot and find an selinuxfs mounted back out on the host system. I think this in turn is going to cause is_selinux_enabled() to return that selinux is in fact enabled. No proof but what i know for sure is that
cat /proc/filesystems | grep -v selinux > /tmp.filesystems mount -o bind /tmp.filesystems /chroot/proc/filesystems
still caused passwd to fail because it thought selinux was enabled....
Ah, yes - the optimization by Steve G changed is_selinux_enabled() to first check for a selinux_mnt previously set upon library init and uses that as indication of being enabled if present; otherwise, it falls back to checking /proc/filesystems.
Regardless, as long as you create /selinux/enforce == 0, you're ok with passwd, right?
not sure, don't know how to get python to write a 0 without a null terminator or EOL or anything like that yet. docs.python.org FTW.
-Eric
not sure, don't know how to get python to write a 0 without a null terminator or EOL or anything like that yet. docs.python.org FTW.
import os
# open a file for writing f = os.open('/tmp/foobar', os.O_WRONLY)
# create a string with a single NULL byte s = '\0'
# write the string f.write(s)
# close the file f.close()
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Eric Paris -
Jeremy Katz -
John Dennis -
Stephen Smalley