linux-kernel - Re: [SECURITY] /proc/$pid/ leaks contents across setuid exec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1r5bglfnu.fsf@fess.ebiederm.org>
Date:	Wed, 09 Feb 2011 19:41:41 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	James Morris <jmorris@...ei.org>
Cc:	Kees Cook <kees.cook@...onical.com>, linux-kernel@...r.kernel.org,
	Al Viro <viro@....linux.org.uk>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	linux-security-module@...r.kernel.org
Subject: Re: [SECURITY] /proc/$pid/ leaks contents across setuid exec

James Morris <jmorris@...ei.org> writes:

> On Tue, 8 Feb 2011, Eric W. Biederman wrote:
>
>> Kees Cook <kees.cook@...onical.com> writes:
>> 
>> > On Tue, Feb 08, 2011 at 02:43:15PM +1100, James Morris wrote:
>
>> >> > I don't think /proc/$pid/* needs to stay open across execs, does it? Or at
>> >> > least the non-0444 files should be handled separately.
>> >> 
>> >> Actually, this seems like a more general kind of bug in proc rather than a 
>> >> leaked fd.  Each child task should only see its own /proc/[pid] data.
>> >
>> > Right, that's precisely the problem. The unprivileged process can read
>> > the setuid process's /proc files.
>> 
>> If these are things that we actually care about we should sprinkle in a
>> few more ptrace_may_access calls into implementations of the relevant
>> proc files.
>
> This seems to be papering over a bug.
>
> It is plainly broken to return an access error to a task which is 
> legitimately accessing a file.  The task should not receive the wrong 
> information from /proc/[pid]/* .

Per task files are special because of exec.  The permission needed
change dynamically.  The common solution to this problem (see ttys) is
to revoke anyone who has file descriptors open.  Proc does something a
little different and simply gives you a permission error when you read
or write if it would be a problem.

We happen to call the test to see if you should have permission
security_may_ptrace because ptrace lets you get the information anyway
so we might as well allow the information from /proc.

Given that security_may_ptrace is the existing model, and that we don't
return wrong data, but a clear an unambiguous error I don't see problems
with the approach.

The practical question is, is the data sensitive enough that we want
this protection.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/