From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC] capabilities: Ambient capabilities Date: Fri, 13 Mar 2015 12:03:25 -0700 Message-ID: References: <933931146caf5dac58379f50c017bff9f6c47661.1426183417.git.luto@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-security-module-owner@vger.kernel.org To: Kees Cook Cc: "Andrew G. Morgan" , Jarkko Sakkinen , Ted Ts'o , Andrew Lutomirski , Andrew Morton , Michael Kerrisk , Mimi Zohar , Linux API , Austin S Hemmelgarn , linux-security-module , Aaron Jones , Christoph Lameter , LKML , Serge Hallyn , Markku Savela , Jonathan Corbet List-Id: linux-api@vger.kernel.org On Fri, Mar 13, 2015 at 11:52 AM, Kees Cook wrote: > > All this said, almost half of the capabilities, if passed to flawed > children with attacker controlled execution, can be elevated to full > root privileges pretty easily[1], so I think any documentation around > this feature should include some pretty dire warnings about using > this. That's a good point. I'll make sure to document that. It's worth noting that, for many applications, that list is overstated. For example, many of the suggested privilege escalations don't work if you're in a sufficiently restrictive mount namespace. For my own use, I plan on adding only CAP_NET_BIND_SERVICE and CAP_NET_RAW to pA, and I'll be layering seccomp on top to the extent possible. --Andy > > -Kees > > [1] https://forums.grsecurity.net/viewtopic.php?f=7&t=2522 > > -- > Kees Cook > Chrome OS Security -- Andy Lutomirski AMA Capital Management, LLC