Re: boost::asio and seccomp

--===============2971689704888199807==
Content-Type: multipart/signed; boundary="Sig_/36v0M9m7NG11.htmLCZXIFa";
 protocol="application/pgp-signature"; micalg=pgp-sha512

--Sig_/36v0M9m7NG11.htmLCZXIFa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 17 Nov 2025 15:31:18 -0300
Vin=C3=ADcius dos Santos Oliveira <[email protected]> wrote:

> Em seg., 17 de nov. de 2025 =C3=A0s 13:09, Marek K=C3=BCthe
> <[email protected]> escreveu:
> > Hello, =20
>=20
> Hi Marek,
>=20
> I have lots of experience with containerization & sandboxing on Linux
> (and FreeBSD), but very few people to talk to about it (which I do
> miss more of). Let's keep in contact after I try to help answer your
> questions.

My contact details are on my website: https://mk16.de/about_me/

>=20
> > I would like to make my program more secure under Linux with seccomp.
> > My question is: how can I query which backend boost::asio uses (epoll,
> > select, etc.)? =20
>=20
> Boost.Asio doesn't have fallback logic. You choose which backend to
> use at compile time by defining macros.
>=20
> Given most vendors disable io_uring nowadays[1], the ideal
> implementation would not work as Boost.Asio does. The ideal
> implementation would have fallback logic and try io_uring first. This
> would also help with sandboxes because seccomp is a terrible model to
> secure io_uring in capability sandboxes (io_uring communicates with
> the kernel through message writes, but seccomp only filters syscalls).
> So if Boost.Asio had fallback logic your application would be able to
> fork the process, and disable io_uring. On the forked process,
> Boost.Asio could use epoll while the parent process would use
> io_uring. That's not possible today.

However, io_uring also appears to have three syscalls:
```
$ ausyscall --dump | grep io_uring
425	io_uring_setup
426	io_uring_enter
427	io_uring_register
```

However, boost::asio does not seem to use them. So if boost::asio uses
io_uring (BOOST_ASIO_HAS_IO_URING_AS_DEFAULT), do I not need seccomp
for it?

> Landlock is a promising new Linux approach that won't ever replace
> seccomp, but has the potential to secure some interfaces that seccomp
> can't. Until Landlock is mature and more complete, we have to do stuff
> such as avoiding io_uring entirely within sandboxes. For Boost.Asio
> this means using the epoll backend.

As far as I understand, you have to explicitly enable this in the
kernel. Does Debian do this by default? If not, it's not worth my while
to look into it, as I want to deploy the program productively on Debian
later on.

> > I would also like to know which system calls boost::asio
> > uses for which Linux backend. =20
>=20
> io_uring doesn't use syscalls so there's no point in filtering
> syscalls to secure io_uring.
>=20
> For the epoll backend, everyone does basically the same things. Just
> go through the list of syscalls and enable everything epoll-related.
> You can look at Kafel for an easy to use language to define seccomp
> policies. I wrote a few policy groups if you're interested.

I had been using libseccomp until now. Does Kafel offer any advantages?
My previous code is in
https://codeberg.org/mark22k/crazytrace/src/commit/d507ff13256d7e2f69635306=
924814356d35ad6e/src/seccomp.cpp
and
https://codeberg.org/mark22k/crazytrace/src/commit/d507ff13256d7e2f69635306=
924814356d35ad6e/src/main.cpp.

> The only weird thing about Boost.Asio is that it still relies on the
> ancient'n'fragile FIONBIO[2] instead of fcntl/O_NONBLOCK by default
> (and MSG_DONTWAIT when available to save syscalls/performance). I
> complained to Chris until he fixed almost all of my complaints.
> Nowadays you can use Boost.Asio in many models of capability
> sandboxes, but not all. The only missing piece is MSG_DONTWAIT which
> matters to avoid DoS when file descriptors are shared among untrusted
> processes (necessary for capability sandboxes).

Hmm, boost::asio seems to use fcntl for me. Do you know which syscalls
need to be enabled for FIONBIO (ioctl?) and how to check whether
boost::asio uses FIONBIO or fcntl?

> I wrote a very detailed article explaining how to develop sandboxes
> for Linux and FreeBSD, but I suspect only 2 people have actually read
> the whole thing:
> https://blog.emilua.org/2025/01/12/software-sandboxing-basics/

I currently use libcap-ng in addition to seccomp. In my opinion,
libcap-ng was much easier to use (but that may be because I know the
caps I need better than the syscalls).

> The described model is implemented in Emilua which is a runtime
> (similar to NodeJS) for LuaJIT using Boost.Asio (you can also
> configure it to use the standalone version of ASIO if you want).
> Emilua is also a container runtime. You can prototype stuff quickly in
> Lua using Emilua and implement a high-performance version in pure C++
> later if the need arises. That's the last demo I made for Emilua:
> https://www.youtube.com/watch?v=3Danu-onpDMBc
>=20
> I'm now keeping in contact with Matthew Flatt to implement sandboxes
> for Racket. However Racket doesn't use Boost.Asio.
>=20
> I'm also designing a thing to more easily implement sandboxes in C++,
> but it's still too soon to show this work.
>=20
> I've tried to collaborate with JS runtime developers to implement
> sandboxes too, but every time I've left these meetings frustrated. JS
> guys have no ambition at all. They only want to mirror what NodeJS
> already does (and perhaps do the same stuff but only slightly faster).
> I have no intention to collaborate with JS communities again. I want
> to collaborate with ambitious programmers who want to do more than
> what's possible today. I don't want to collaborate with programmers
> whose souls are already dead.
>=20
> > Can anyone help me with this? Is this documented anywhere? =20
>=20
> There's no documentation. I hope my attempts to explain seccomp,
> io_uring and Boost.Asio were useful to you.
>=20
> [1] https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-l=
inux.html
> [2] https://stackoverflow.com/a/1151077/883113
>=20
>=20
> _______________________________________________
> asio-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio


--=20
Marek K=C3=BCthe
[email protected]
er/ihm he/him

--Sig_/36v0M9m7NG11.htmLCZXIFa
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmqKBWfzrPNg7whIBfoaRRmmRCMcFAmkcsXUACgkQfoaRRmmR
CMeNFw/+LITbuTvUIyeQcSyqzYUprR6iPxADRtcA5l7K7TQ+Cm1m7osZ+abeh4lh
IcvIsmNyOg2UqG1SFIPj76oQoHccu7RiwhYoW/3HL5BAOWsAuP/GL1wanoW0mnX8
EIgSlBmKn2e9EKMEcVyfaVWyIJden9To6F8dTDYRbsa8unUsbKeweNtSm7Q/wbBr
3vgmv7vr42ByW7n1k2utU1JUwn/B2gNYuNu+38EGlUpqd6aLBHWJP7aL5AehOmZm
YJ1lDs6a8CHEG56k0D2F+kmO3SkP5249Wy+INJbyt4fd9pUU5GaMpYysB0jr0JVq
mdb9jJId3w2bNELseaXTvVvtQ1ebVp932JZBGVov/Gf1Sjztc8+W7/hUoCFB19oN
VGl9xu5FHqiF7R2djoYs0junnkmez5RgrnfmCPj8MuIB30qVaX9NK/YI6ZBnb+Uv
9l3oBKiWpLc4pZGnEPkpeWCEHyZR4CoYvKolA+RCidD34gBEO3LwI7s38xptR1gx
leV8dTWDhP7c2PVEx0THB65K7yO5PqtLKKiac1uogOyOca1aMXlQ74xs2qm5tUcV
pvX5W2j3g6RjMlHabegWEeX/3dz+sC0ag8bJ/+b+hGSgc1WM7WBCRRtUyZpCIuL5
S4CCKYabTKkSNrX5eMKdeWp2OBR0N2/D6u+rM5PdQYh2GgyMnrw=
=5UJL
-----END PGP SIGNATURE-----

--Sig_/36v0M9m7NG11.htmLCZXIFa--


--===============2971689704888199807==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============2971689704888199807==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
asio-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

--===============2971689704888199807==--