Re: [PATCH 06/12] procfs: make /proc/*/stack 0400

[Kees Cook]

On Sat, Sep 28, 2013 at 7:35 AM, Djalal Harouni <tixxdz@xxxxxxxxxx> wrote:
> On Thu, Sep 26, 2013 at 03:43:24PM -0500, Kees Cook wrote:
>> On Wed, Sep 25, 2013 at 3:14 PM, Djalal Harouni <tixxdz@xxxxxxxxxx> wrote:
>> > The /proc/*/stack contains sensitive information and currently its mode
>> > is 0444. Change this to 0400 so the VFS will be able to block
>> > unprivileged processes to get file descriptors on arbitrary privileged
>> > /proc/*/stack files.
>> >
>> > The /proc/*/stack is a /procfs ONE file that shares the same ->open()
>> > file operation with other ONE files. Doing a ptrace_may_access() check
>> > during open() might break userspace from accessing other ONE files
>> > like /proc/*/stat and /proc/*/statm.
>> >
>> > Therfore make it 0400 for now, and improve its check during ->read()
>> > in the next following patch.
>> >
>> > Cc: Kees Cook <keescook@xxxxxxxxxxxx>
>> > Cc: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
>> > Signed-off-by: Djalal Harouni <tixxdz@xxxxxxxxxx>
>>
>> While the rest of the series is being discussed, I think it would be
>> nice to at least get this into the tree. Fixing this reduces which
>> processes are exposed to ASLR leaks. The rest of the series closes the
>> remaining holes.
>>
>> I would if it would be valuable adding a test for the identified leak
>> conditions to some test suite? LTP perhaps?
> I'm not familiar with LTP, but I guess a small program that perform I/O
> redirection and execve a suid-exec will do it?

It's actually a giant program. :)

http://ltp.sourceforge.net/

> I'll try to add code comment in fs/proc/base.c

Mostly I'm just thinking that this is a rather fragile area, and it
would be nice to have a set of tests that verify we haven't broken any
of the known test-cases.

-Kees

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