The "anet" pledge says that "this allows to accept, but not initiate socket connections"...but then still appears to allow for creating new AF_INET SOCK_DGRAM sockets and sendto, which allows for sending UDP packets without an established connection. That's probably a sandbox escape on a lot of systems, since you could sendto localhost UDP daemons.
In general the pledge syscall filters are very permissive, which makes it hard to be sure of security; Chromium libsandbox is insanely restrictive in contrast, because that's really what's needed to be confident in your attack surface, especially if you start worrying about kernel privilege escalation exploits like Chrome does. I wasn't aware of the landlock LSM before this, though, which seems pretty neat and a lot less intrusive than selinux for application specific white/blacklisting.
It needs to be able to send unix datagrams so it can blackhole your IP address in the RAW PREROUTING iptable if you DDOS the system. https://github.com/jart/cosmopolitan/blob/f10845ab9f847e4cad... You can't ban someone's IP without root. So we have two choices: (1) create a setuid binary the web server can launch that does it, or (2) run a daemon as root that listens for AF_UNIX datagrams. To do (1) I'd need to grant fork() + execve() privileges, which I view as more problematic than (2) which only needs sendto (possibly even just write). You've helped me realize that I can make the blackholed integration much tighter than the way it's currently being implemented in https://github.com/jart/cosmopolitan/blob/f10845ab9f847e4cad... so thank you!
As for surface area, I expected people to rake me over the coals for blocking io_uring. I didn't anticipate support for Google's zeal. OpenBSD is actually even more permissive than me when it comes to letting stuff through pledge("stdio"). https://github.com/openbsd/src/blob/fb5793d3d4d0fd4795586dd9... Also surface area isn't a weakness, it's a paradigm. If a weakness actually exists, then you must exploit it. So long as you tell us what you did, for the post-mortem.
I was specifically talking about AF_INET dgram sockets, not AF_UNIX; I saw that it wasn't pledged and assumed that was by design (since having that and sendto would be extremely unsafe, since you could connect to abstract unix sockets). If you want to use an inherited unix socket for the blacklisting, you should use SOCK_STREAM unix sockets instead so you can't sendto. Even allowing localhost UDP sockets isn't safe to expose to a sandbox, IMO, since Linux programs fairly often expose privileged operations over those and have no way of knowing the client is supposed to be sandboxed and rejected.
I see what you mean now. When we created the "anet" category, the main intent was to prevent redbean from making outbound HTTP connections. Allowing UDP looks like a copy and paste error. You're correct that it is a weakness. Thank you for identifying it! I'm in the process of fixing it now. How would you like to be credited?
I haven't followed cosmopolitan / Linux pledge() too closely; but I notice your SERVER_PLEDGE and CLIENT_PLEDGE include stdio, so I expect you have write(2) (and could thus handle a pipe, and maybe even a passed-in AF_UNIX socket?)
Or is making the challenge more interesting - by actually including some networking - part of the fun?
In general the pledge syscall filters are very permissive, which makes it hard to be sure of security; Chromium libsandbox is insanely restrictive in contrast, because that's really what's needed to be confident in your attack surface, especially if you start worrying about kernel privilege escalation exploits like Chrome does. I wasn't aware of the landlock LSM before this, though, which seems pretty neat and a lot less intrusive than selinux for application specific white/blacklisting.