Re: [PATCH v2 1/4] capabilities: Add user namespace capabilities
"Serge E. Hallyn" <[email protected]> Sat, 15 Jun 2024 10:19:08 -0500
| Newsgroups | dev.linux.lists.containers,org.kernel.vger.bpf,org.kernel.vger.keyrings,org.kernel.vger.linux-doc,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-security-module,org.kernel.vger.selinux |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Jun 11, 2024 at 01:20:40AM -0700, Jonathan Calmels wrote: > On Mon, Jun 10, 2024 at 08:00:57AM GMT, Serge E. Hallyn wrote: > > > > Now, one thing that does occur to me here is that there is a > > very mild form of sendmail-capabilities vulnerability that > > could happen here. Unpriv user joe can drop CAP_SYS_ADMIN > > from cap_userns, then run a setuid-root program which starts > > a container which expects CAP_SYS_ADMIN. This could be a > > shared container, and so joe could be breaking expected > > behavior there. > > > > I *think* we want to say we don't care about this case, but > > if we did, I suppose we could say that the normal cap raise > > rules on setuid should apply to cap_userns? > > > > Right, good catch. If we do want to fix it, we could just check for > setuid no? Or do we want to follow the normal root inheritance rules > too? Essentially something like this: > > pU' = is_suid(root) ? X : pU Yeah, I think that makes sense. Thanks. -serge