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.

    There are too many mechanisms that pretend to control applications
in the place of the applications themself, and practically out of
admin's control: SELinux, Apparmor, Capabilities, POSIX ACLs. Two other
mechanism seem better: Pledge and Landlock. Here's a review of my own
understanding of all them. I've a very limited experience of Linux
capabilities, which I don't like, and a more serious one of Landlock.
Please correct my errors and ignorance, so that I could have a global view.

   -  SELinux: I've read Selinux was being deprecated by Apparmor. I've
no idea how it works. AFAIU, it works under the hood, out of the control
of the user and even the admin, because of of its complexity.

   - 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.

   - POSIX ACL: Xattrs are used also to implement ACL. IIUIC, ACLs are
something Microsoft succeeded to get standardized by POSIX. Linux
implements it by the means of extended attributes, I don't know for
which use other than claiming "POSIX compliance".

   - Apparmor: The documentation of Apparmor talks of "capabilities"
but it is not clear wether these capabilities are those mentionned above
and stored in file's extended attributes or just the use of the same
word to mean something similar but different. AFAIU, Apparmor relies on
applications' profiles, something which dosn't exist for Linux
capabilities. It seems to have the same defects as SELinux: practically
impossible to manage by the admin. I mean a professional admin could
manage it for a set of professional computers, but it shouldn't be
installed by default on a desktop computer.

   - Pledge: Pledge is the OpenBSD security feature, a priori more
respectable than ACLs. The interesting feature, compared to Linux
capabilities, is that the fine-grained configuration of permissions is
set by the program itself instead of invisible executable file
attributes. I imagine the typical program is suid, meaning it has root
priviledge but defines itself the permissions it really needs in a
contract it passes with the kernel, and which the kernel then enforces.
AFAIU, Pledge declares which system-calls it needs and forbids all the
others. In apparence the same is true for Linux capabilities: the
program itself requires the capabilities it needs. But it cannot excceed
the ones which are writen in its xattrs. Since there is no reason to set
in the xattrs more than it needs, the required and the permitted are the
same and are defined in the xattrs. In conclusion, Pledge is equivalent
to Linux capabilities, but without the invisible extended attributes;
for this reason I'd lean to find it superior.

   - Landlock: Landlock "restrictions" are set by the program itself,
in the same fashion as Pledge, and are inherited by any child process or
executed program. The difference is that Landlock does not restrict
system calls globally, but a very fine-grained set of file system access
rights attached to files and/or directory trees; it can also restrict
network access rights, and the access to abstract sockets and sending
signals. For example it can request the right to write a file but
neither truncate nor create it; or it can deny itself the right to
rename any file or directory. Landlock access-rights are attached to the
objects, rather than globally to system-calls. AFAIU, it is the most
fine-grained, therefore the most securing of all security mechanisms. It
works by globally denying itself a large set of access rights and then
introducing selected exceptions for selected objects. It is very new,
evolving quickly and still has no wrapper in any C runtime library,
other than through the syscall() function. From my programmer and user's
point of view, it is by far superior to all the other "sandboxing"
mechanisms.

    Both Pledge and Landlock allow applications which need priviledges
to be clearly identified because the file permissions of their
executable exhibits the suid bit. And, in the same time, they protect
themself of "abusing" the root priviledge to do bad things either by
error or by exploit. It seems to me that Landlock provides a more
fine-grained, therefore more comprehensive control.

--     Didier