On Wed, Aug 17, 2022 at 12:49 PM Casey Schaufler [off-list ref] wrote:

On 8/17/2022 9:10 AM, Paul Moore wrote:

quoted

On Wed, Aug 17, 2022 at 11:50 AM Casey Schaufler [off-list ref] wrote:

quoted

On 8/17/2022 7:52 AM, Paul Moore wrote:

quoted

On Wed, Aug 17, 2022 at 7:53 AM Francis Laniel
[off-list ref] wrote:

quoted

Le mardi 16 août 2022, 23:59:41 CEST Paul Moore a écrit :

quoted

On Mon, Jul 25, 2022 at 8:42 AM Francis Laniel

[off-list ref] wrote:

quoted

Hi.

First, I hope you are fine and the same for your relatives.

Hi Francis :)

quoted

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.

...

quoted

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

I believe this could be a significant help in encouraging the use of
capabilities. An application that has to know the list of capabilities
at compile time but is expected to run unmodified for decades isn't
going to be satisfied with cap_last_cap. The best it can do with that
is abort, not being able to ask an admin what to do in the presence of
a capability that wasn't around before because the name isn't known.

An application isn't going to be able to deduce the semantic value of
a capability based solely on a string value,

True, but it can ask someone what to do, and in that case a string is
much better than a number ...

If you are asking a user what to do, that user can just as easily look
up the capability list to translate numbers to intent.  If your
security approach requires a user knowing all of the subtle details
around a capability based on 10~15 character string, I wish you the
best of luck :)

-- 
paul-moore.com