linux-kernel - Re: [RFC PATCH v4 0/2] Add capabilities file to securityfs

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: <CAHC9VhSMeefG5W_uuTNQYmUUZ1xcuqArxYs5sL9KOzUO_skCZw@mail.gmail.com>
Date:   Wed, 17 Aug 2022 10:52:34 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Francis Laniel <flaniel@...ux.microsoft.com>
Cc:     linux-security-module@...r.kernel.org,
        Casey Schaufler <casey@...aufler-ca.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        Serge Hallyn <serge@...lyn.com>,
        James Morris <jmorris@...ei.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:BPF [MISC]" <bpf@...r.kernel.org>
Subject: Re: [RFC PATCH v4 0/2] Add capabilities file to securityfs

On Wed, Aug 17, 2022 at 7:53 AM Francis Laniel
<flaniel@...ux.microsoft.com> wrote:
> Le mardi 16 août 2022, 23:59:41 CEST Paul Moore a écrit :
> > On Mon, Jul 25, 2022 at 8:42 AM Francis Laniel
> >
> > <flaniel@...ux.microsoft.com> wrote:
> > > Hi.
> > >
> > > First, I hope you are fine and the same for your relatives.
> >
> > Hi Francis :)
> >
> > > A solution to this problem could be to add a way for the userspace to ask
> > > the kernel about the capabilities it offers.
> > > So, in this series, I added a new file to securityfs:
> > > /sys/kernel/security/capabilities.
> > > The goal of this file is to be used by "container world" software to know
> > > kernel capabilities at run time instead of compile time.
> >
> > ...
> >
> > > The kernel already exposes the last capability number under:
> > > /proc/sys/kernel/cap_last_cap
> >
> > I'm not clear on why this patchset is needed, why can't the
> > application simply read from "cap_last_cap" to determine what
> > capabilities the kernel supports?
>
> When you capabilities with, for example, docker, you will fill capabilities
> like this:
> docker run --rm --cap-add SYS_ADMIN debian:latest echo foo
> As a consequence, the "echo foo" will be run with CAP_SYS_ADMIN set.
>
> Sadly, each time a new capability is added to the kernel, it means "container
> stack" software should add a new string corresponding to the number of the
> capabilities [1].

Thanks for clarifying things, I thought you were more concerned about
detecting what capabilities the running kernel supported, I didn't
realize it was getting a string literal for each supported capability.
Unless there is a significant show of support for this - and I'm
guessing there isn't due to the lack of comments - I don't think this
is something we want to add to the kernel, especially since the kernel
doesn't really care about the capabilities' names, it's the number
that matters.

-- 
paul-moore.com