On Wed, 25 Feb 2026 12:25:48 +0100
Didier Kryn <kryn@???> wrote:

> Le 24/02/2026 à 22:30, Andrew Bower a écrit :
> > 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.
>
>     My limited experience on Linux capabilities is that this mechanism
> is incompatible with suid root: an suid root program which has no
> capabilities in its executable file cannot gain them despite its root
> priviledge. This would be usefull because it could then drop its root
> priviledge and be restricted to the capabilities it has set itself. The
> consequence is that the capabilities must be stored in the (hidden)
> extended attributes, in which case, of course, the program doesn't need
> to be suid root.
>
>     Landlock features a great deal of access rights to files and
> directories, eg: write, create, truncate, delete, mv, are different
> rights instead of being all controled by the only write permission. But
> there is still no particular right associated to mount(), which opens a
> large attack surface.
>
> --     Didier
>

Quis custodiet ipsos custodes?
Ciao,
Tito