Re: [asio-users] boost::asio and seccomp

[Vinícius d. S. O. <vin...@gm...>]

Em seg., 17 de nov. de 2025 às 13:09, Marek Küthe
<m-k...@mk...> escreveu:
> Hello,

Hi Marek,

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.

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

Boost.Asio doesn't have fallback logic. You choose which backend to
use at compile time by defining macros.

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.

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.

> I would also like to know which system calls boost::asio
> uses for which Linux backend.

io_uring doesn't use syscalls so there's no point in filtering
syscalls to secure io_uring.

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.

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

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/

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=anu-onpDMBc

I'm now keeping in contact with Matthew Flatt to implement sandboxes
for Racket. However Racket doesn't use Boost.Asio.

I'm also designing a thing to more easily implement sandboxes in C++,
but it's still too soon to show this work.

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.

> Can anyone help me with this? Is this documented anywhere?

There's no documentation. I hope my attempts to explain seccomp,
io_uring and Boost.Asio were useful to you.

[1] https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html
[2] https://stackoverflow.com/a/1151077/883113