Messages in this thread | | | Subject | Re: compute_creds fixup in -mm | From | Stephen Smalley <> | Date | Wed, 21 Apr 2004 14:13:19 -0400 |
| |
On Wed, 2004-04-21 at 13:27, Andy Lutomirski wrote: > This doesn't fix selinux, though -- its apply_creds hook just blindly calls > commoncap's. In fact, this breaks all attempts to get nested capability modules > right. The problem is that, AFAICS, not only does ptrace_detach not take > task_lock, _exit() doesn't either. So you get an equivalent race for the shared > state check. I see two ways to fix that:
I didn't see Chris' patch. I assume that the worst case is unexpected program failure due to lack of capability, right? The SELinux security transitions aren't tied to the uid/capability evolution anyway, and SELinux provides its own separation among differing security domains, including the kernel access controls and enabling glibc secure mode.
Side bar: Why does the uid/capability logic proceed under the old uid/capability set rather than aborting the exec? SELinux leaves the task SID unchanged and forces a SIGKILL, as we don't really want the program proceeding under the wrong permission set anyway.
> 1. something checks for shared state _once_ and saves it either in the binprm or > passes it as a parameter to apply_creds. apply_creds needs to be changed so > that the task_lock is taken by the caller.
Likely a good idea.
> This one also (hopefully) fixes selinux. > > Patch against 2.6.5-mm5.
Didn't apply for me. Also would help to rebase to 2.6.6-rc2-mm1.
> --- linux-2.6.5-mm5/security/selinux/hooks.c.ptlock 2004-04-21 08:57:16.947281304 -0700 > +++ linux-2.6.5-mm5/security/selinux/hooks.c 2004-04-21 09:22:15.227508088 -0700 > @@ -1782,14 +1780,13 @@ > /* Check for ptracing, and update the task SID if ok. > Otherwise, leave SID unchanged and kill. */ > task_lock(current);
Above line needs to be deleted, right?
-- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |