Em seg., 17 de nov. de 2025 às 13:09, Marek Küthe <[email protected]> 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 _______________________________________________ Boost-users mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.boost.org/mailman3/lists/boost-users.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/[email protected]/message/YJ5RTK25HLPFEZ3XVBBFQDJOSPIIOBNA/
