linux-kernel - Re: RFC: capabilities(7): notes for kernel developers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1928427a-d29b-e625-37a0-52e9ffecc7e1@gmail.com>
Date:   Fri, 16 Dec 2016 16:04:02 +0100
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     Casey Schaufler <casey@...aufler-ca.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        James Morris <jmorris@...ei.org>,
        Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...capital.net>,
        John Stultz <john.stultz@...aro.org>,
        Jann Horn <jann@...jh.net>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     mtk.manpages@...il.com, linux-man <linux-man@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: capabilities(7): notes for kernel developers

On 12/15/2016 09:40 PM, Casey Schaufler wrote:
> On 12/15/2016 11:41 AM, Michael Kerrisk (man-pages) wrote:
>> Hello Casey,
>>
>> On 12/15/2016 05:29 PM, Casey Schaufler wrote:
>>> On 12/15/2016 3:40 AM, Michael Kerrisk (man-pages) wrote:

[...]

>>>>        *  To determine which existing capability might best be associated
>>>>           with your new feature, review the list of capabilities above in
>>>>           order to find a "silo" into which your new feature best fits.
>>> One approach to take is to determine if there are other features
>>> requiring capabilities that will always be use along with the
>>> new feature. If the new feature is useless without these other
>>> features, you should use the same capability as the other features.
>> Thanks, I've lifted those words exactly as you gave them into the man page.
>>
>>>>        *  Don't choose CAP_SYS_ADMIN if you can  possibly  avoid  it!   A
>>>>           vast  proportion  of  existing capability checks are associated
>>>>           with this capability, to the point where it  can  plausibly  be
>>>>           called "the new root".  Don't make the problem worse.  The only
>>>>           new features that should be associated with  CAP_SYS_ADMIN  are
>>>>           ones that closely match existing uses in that silo.
>>> I don't agree with this advice. Use CAP_SYS_ADMIN if you are
>>> preforming system administration functions. Odds are very good
>>> that if a program is using one system administration feature
>>> it will be using others. 
>> Really? To me, the CAP_SYS_ADMIN situation is a terrible mess.  Around a
>> third of all of the capability checks in the kernel are for that
>> capability. Or, to put it another way, it is so broad, that if a process
>> has to have that capability, it may as well be root.  And because it is
>> so broad, the number of binaries that might need that file capability is
>> large. (See also https://lwn.net/Articles/486306/)
> 
> Back in the days of the POSIX P1003.1e/2c working group
> we struggled with what to do about the things that required
> privilege but that were not related to the enforcement of
> security policy. Everyone involved was looking to use
> capabilities to meet B2* least privilege requirements in
> NSA security evaluations. Because those evaluations where
> of security policy, by far the easiest thing to do was to
> create a single capability for all the things that didn't
> show up in the security policy and declare that the people
> doing the evaluation didn't have to look over there. Since
> then, people have taken a more practical view that includes
> security relevance in addition to security policy.

Ahhh -- thanks for a bit of the history! Helps me to
understand a bit more why things are as they are...

> In retrospect we should have grouped all of the attribute
> changes (chmod, chown, ...) into one capability and broken
> the non-policy actions into a set on 2 or three.
> 
> The way that we think of privilege has evolved. We're not
> focused on policy the way we used to be. We'll never get
> everyone to agree on what the *right* granularity and
> grouping is, either.

:-)

> -----
> * The B2 least privilege requirements are amusing.
>   If you want more information, look up "TCSEC orange book".

Maybe one day...

[...]

Cheers,

Mcihael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/