From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933713AbbFJTZL (ORCPT ); Wed, 10 Jun 2015 15:25:11 -0400 Received: from mail-vn0-f54.google.com ([209.85.216.54]:39114 "EHLO mail-vn0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753428AbbFJTY7 (ORCPT ); Wed, 10 Jun 2015 15:24:59 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 10 Jun 2015 12:24:58 -0700 X-Google-Sender-Auth: VmJS90ElJeVf9BAoT4KvKh0hV6Q Message-ID: Subject: Re: [PATCH v3 1/2] capabilities: Ambient capabilities From: Kees Cook To: Andy Lutomirski Cc: Andy Lutomirski , Serge Hallyn , Andrew Morton , James Morris , Jarkko Sakkinen , "Ted Ts'o" , "Andrew G. Morgan" , Linux API , Mimi Zohar , Michael Kerrisk , Austin S Hemmelgarn , linux-security-module , Aaron Jones , Serge Hallyn , LKML , Markku Savela , Jonathan Corbet , Christoph Lameter Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 9, 2015 at 5:00 PM, Andy Lutomirski wrote: > On Tue, Jun 9, 2015 at 4:09 PM, Kees Cook wrote: >> On Wed, May 27, 2015 at 4:47 PM, Andy Lutomirski wrote: >>> [1] Files that are missing the "security.capability" xattr or that >>> have unrecognized values for that xattr end up with has_cap set to >>> false. The code that does that appears to be complicated for no >>> good reason. >> >> Would it make more sense to have has_cap true, but have it lack any actual caps? > > I assume you're referring to the case where we fail to parse the > xattr. If so, I don't really know if or when this happens. Should > that be addressed separately from this patch set? No, no. All of these footnotes seem to be separate from the series. I just wanted to chime in on them, since none of them really sounded like they should get dropped. >>> [2] The libcap capability mask parsers and formatters are >>> dangerously misleading and the documentation is flat-out wrong. fE >>> is *not* a mask; it's a single bit. This has probably confused >>> every single person who has tried to use file capabilities. >> >> Sounds like it would be a valuable documentation patch. > > I'll try. Let's get the current thing done first. Yup! No worries. I'm happy to help with the docs, too. >>> [3] Linux very confusingly processes both the script and the >>> interpreter if applicable, for reasons that elude me. The results >>> from thinking about a script's file capabilities and/or setuid bits >>> are mostly discarded. >> >> I wonder if this is important enough to fix? > > Not sure. > > However, the fact that AFAICT LSM due to a script (as opposed to an > interpreter) is preserved sounds rather dangerous to me. I'm not sure > whether we can safely fix that at this point. Agreed. I missed adding: Acked-by: Kees Cook I would love to use this already. :) -Kees -- Kees Cook Chrome OS Security