Re: [PATCH] proc: Use sane permission checks on the /proc/<pid>/fd/ symlinks.

[ebiederm@xmission.com (Eric W. Biederman)]

Andrew Morton <akpm@osdl.org> writes:

> With all your latest patches I get a big spew lateish in the boot:
>
> Reverting just this patch prevents the above.
>
> This is with basically unaltered FC5 as of a few days ago.  The audit
> patches weren't applied.
>
> What is happening is that both `current' and get_proc_task(inode) are the
> same task_struct: `restorecon' is trying to read its own proc files.  But
> ptrace_may_attach()->security_ptrace() is returning -EACCES.
>
> So I bodged it in the obvious manner:

Ugh.  Unless I am misreading the code we have the exact same problem
with /proc/self/mem.  Which uses a stricter form of the same test.

> btw, it's surprising (to me) that security_ptrace(t1, t2) fails when
> t1==t2?

Same here.  ptrace_attach explicitly denies that case but that happens
outside of ptrace_may_attach to allow for the /proc usage.

> --- devel/fs/proc/base.c~proc-use-sane-permission-checks-on-the-proc-pid-fd-fix
> 2006-03-03 00:38:17.000000000 -0800
> +++ devel-akpm/fs/proc/base.c	2006-03-03 00:43:54.000000000 -0800
> @@ -521,8 +521,11 @@ static int proc_fd_access_allowed(struct
>  	 * allow access if we have the proper capability.
>  	 */
>  	task = get_proc_task(inode);
> -	if (task) {
> +	if (task == current)
> +		allowed = 1;
> +	if (task && !allowed) {
>  		int alive;
> +
>  		task_lock(task);
>  		alive = !!task->mm;
>  		task_unlock(task);
>
> And the messages went away.

Agreed.  Examining your self should always be valid.

I suspect this check get put in ptrace_may_attach, so we can always
read /proc/self/mem.

> But I have a bad feeling about these /proc permission changes, Eric.  I
> suspect we'll be chasing a gradually decreasing frequency of weird problems
> for a long time.

You may be right, but even if that is the case I think it is worth it.
The old checks were bizarre if not outright wrong.  And cause their
own share of weird cases when you start using things like namespaces.

The checks unify the two cases where we allow violating a tasks
privacy.  Which is an important case to get right, and unification
of permissions means it is easier to administer if you don't want
someone doing that.

/proc and ptrace have had a connection since at least 2.0 so this
is nothing new.  So if by using this on more than just /proc/<pid>/mem
I increase the frequency of usage and thus increase the frequency
of problem detection I think it is a good thing.

I think it is actually surprising no one noticed how bogus the
permissions on /proc/<pid>/fd/<fd#> have been, especially the people
concerned with security.

> That task_lock() you have in proc_fd_access_allowed() looks very fishy,
> btw.  As soon as the lock is dropped, local `alive' becomes meaningless. 
> Either that, or the lock wasn't needed.

Agreed.  That does look a fishy. 

I also spotted an outright bug. put_task_struct does not work on a
NULL pointer. Duh.

Sorry I obviously didn't switch levels very well when auditing that
code.

I will send in a patch to clean up those bits.

Eric


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