On Sat, Oct 01, 2016 at 08:16:00PM -0700, Krister Johansen wrote: > On Fri, Sep 23, 2016 at 10:40:38PM +0200, Jann Horn wrote: > > +===================== > > +FILESYSTEM DEBUG APIS > > +===================== > > + > > +The pid / tgid entries in procfs contain various entries that allow debugging > > +access to a process. Interesting entries are: > > + > > + - auxv permits an ASLR bypass > > + - cwd can permit bypassing filesystem restrictions in some cases > > + - environ can leak secret tokens > > + - fd can permit bypassing filesystem restrictions or leak access to things like > > + pipes > > + - maps permits an ASLR bypass > > + - mem grants R+W access to process memory > > + - stat permits an ASLR bypass > > + > > +Of these, all use both a normal filesystem DAC check (where the file owner is > > +the process owner for a dumpable process, root for a nondumpable process) and a > > +ptrace_may_access() check; however, the DAC check may be modified, and the > > +ptrace_may_access() is performed under PTRACE_FSCREDS, meaning that instead of > > +the caller's ruid, rgid and permitted capabilities, the fsuid, fsgid and > > +effective capabilities are used, causing the case where a daemon drops its euid > > +prior to accessing a file for the user to be treated correctly for this check. > > Thanks for writing this up. > > Is it worth mentioning some of the less obvious aspects of how user > namespaces interact with the filesystem debug APIs? Of particular note: > a nondumpable process will always be assigned the global root ids. > Checks against capabilities for procfs require that the uid and gid have > a mapping in the current namepsace. That's enforced through > capable_wrt_inode_uidgid(). Yeah, makes sense. Added that. Thanks!
Attachment:
signature.asc
Description: Digital signature
