[lkml]   [2013]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 0/9] procfs: protect /proc/<pid>/* files with file->f_cred

* Djalal Harouni <> 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

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.



 \ /
  Last update: 2013-10-03 09:01    [W:0.188 / U:2.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site