Le 02/03/2026 à 13:07, Kevin Chadwick via Dng a écrit :
>
> -------- Original Message --------
>
>> I have absolutely no authority to judge, but I don't like very much the way
>> Seccomp is implemented. it would be OK for something experimental because no
>> dedicated syscall is needed, but it is still like this after years. Capabilitues
>> and Landlock instead seem to be properly integrated into the kernel.
> On OpenBSD it's just a kernel supported pledge and unveil syscall. I don't know
> anything about seccomp. I guess the ideal of a POSIX API that programmers might
> be happy to use for upstream packages benefitting both OpenBSD and Linux may not
> happen like it is in OpenBSDs base :( . I'm not sure whether the Firefox pledges
> are upstreamed but I think they may be.
>
> Funny how in this review he calls pledge a sandbox when Theo de Raadt is adamant
> that pledge isn't a sandbox and that sandboxing is largely a false sense of
> security for many applications. Another point is that Roy Marples concludes here
> that it is no substitute for good design but of course pledge encourages that.
>
> "https://roy.marples.name/blog/posts/capsicum_vs_pledge_final_thoughts"

    I agree, Pledge, Seccomp, and Landlock aren't sandboxes strictly
speaking. Sandboxing is when the application doesn't see the real OS,
but some fake one instead. chroot is the minimal sandboxing mechanism on
Linux, but it is easy to escape. There are others: Cgroups is one of
them AFAIU, and the ultimate are VMs. But, often the word "sandbox" is
used as a short word to express the idea of establishing a protection
around the program, but it is an abuse of language because the names of
the system objects remain the real ones and the restrictions of rights
are established by the program itself.

    It seems to me that this field isn't mature enough for
standardization and what we are seeing is a flowering of ideas.

    Concerning tools like pmount or qmount, true sandboxing makes no
sense because the command is meant to act on the real system. But
restriction of rights are welcome.

    Linux capabilities are yet another concept. It is not a
/restriction/ of rights, it is a limited, granular, /extension/ of
rights, meant to replace the extreme extension of rights to omnipotence
which is given by the suid file property. But, well, Unixes have lived
with the suid property from the beginning.

--     Didier