On Mon, 2 Mar 2026 17:09:36 +0100
Didier Kryn <kryn@???> wrote:

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

Just as expected:

The AppArmor Linux kernel security module used notably by Ubuntu Linux and currently maintained
by Canonical has been affected by several vulnerabilities made public today.

Qualys researchers discovered vulnerabilities within the AppArmor code of the Linux kernel
they are calling CrackArmor. Some issues can lead to denial of service to kernel memory
information leaks but when paired with a sudo discovery can together lead to local privilege escalation.

https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt
https://ubuntu.com//blog/apparmor-vulnerability-fixes-available

Ciao,
Tito