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(). By way of example, if you enter a user namespace that doesn't have a mapping for the global root id, then non-dumpable processes are off limits from /proc. The global root ids get mapped to a special id for unresolved mappings. If the process that entered the namespace has CAP_DAC_OVERRIDE/CAP_DAC_READ_SEARCH, these don't suffice to grant any access to the non-dumpable process because the inode has no [ug]id mapping in the particular namespace. -K -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
