lkml.org 
[lkml]   [2004]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: compute_creds fixup in -mm
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.062 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site