Jann Horn <jann@xxxxxxxxx> writes: > 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! That will actually be changing for 4.10. mm->user_ns allows me to use the user namespace id 0 if that id is mapped. Eric -- 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
