On Tue, Feb 24, 2026 at 12:23:08PM +0100, Didier Kryn wrote:
> Le 23/02/2026 à 11:27, Kevin Chadwick via Dng a écrit :
> > -------- Original Message --------
> >
> > > Some claim make a report against AppArmor,  some say report it against the
> > > application package.
> > It would be great if Linux moved forward on the pledge front. The developer and
> > application is best placed to decide how to restrict itself. On the other hand
> > some devs wouldn't do it like I'm betting 7-zip. Sandboxing only really helps on
> > simple programs without much access to executing C binaries anyway and is an
> > easily broken false sense of security otherwise.
[...]
>    - Linux Capabilities: I think I understand what Capabilities are: a set
> of permissions granted to the program by "extended attributes" (xattr) of
> the executable file. The extended attributes are invisible to the user: 
> "ls" doesn't show them and there isn't even a command to show them -- it is
> possible to list the capabilities with "getcap". In addition to be stored in
> invisible file metadata, Linux capabilities do not protect very well because
> programs often need CAP_SYS_ADMIN, which gives almost the same priviledge as
> an suid program. I bet the same is true for Pledge.

I don't think this is representative of how capabilities are used in
Linux. While you can have file capabilities, they are very rarely used.
A typical use case would be to give /usr/bin/ping CAP_NET_RAW to perform
ICMP. This is an improvement on setuid because it provides a smaller
attack surface. However, as I say, this is rare.

More common is external entities - typically systemd units - restricting
what an application may otherwise do. Now here is where I am sympathetic
to Kevin's critique. When a packager is second-guessing the capabilities
needed it may get it wrong and we are at risk of the tail wagging the
dog.

The third scenario is more like the 'pledge' feature you describe, and
this I think ought to meet with approval: before (or in the absence of)
dropping to a non-root user, the application may drop some of root's
capabilities (and elect to keep them when dropping user) to avoid
keeping capabilities it knows it does not need. I don't think in most
cases applications choose to keep CAP_SYS_ADMIN although they do often
need CAP_DAC_OVERRIDE which is a bit of a scattergun it must be
admitted.