Re: [PATCH v2 0/9] procfs: protect /proc//* files with file->f_cred

Ingo Molnar
2013-10-03T06:12:50Z

* Djalal Harouni <tixxdz@opendz.org> wrote:

> > Regardless, glibc uses /proc/self/maps, which would be fine here, right?
>
> I did not touch /proc/self/maps and others, but I'm planning to fix them
> if this solution is accepted.
>
> I'll do the same thing as in /proc/*/stat for maps, let it be 0444, and
> try to delay the check to ->read(). So during ->read() perform
> ptrace_may_access() on currenct's cred and process_allow_access() on
> file's opener cred. This should work.

Aren't read() time checks fundamentally unrobust? We generally don't do
locking on read()s, so such checks - in the general case - are pretty
racy.

Now procfs might be special, as by its nature of a pseudofilesystem it's
far more atomic than other filesystems, but still IMHO it's a lot more
robust security design wise to revoke access to objects you should not
have a reference to when a security boundary is crossed, than letting
stuff leak through and sprinking all the potential cases that may leak
information with permission checks ...

It's also probably faster: security boundary crossings are relatively rare
slowpaths, while read()s are much more common...

So please first get consensus on this fundamental design question before
spreading your solution to more areas.

Thanks,

Ingo