3 ms·
Since the author is using cgi: >However, this is definitely something in the crosshairs of ksql(3): forking a process, like kcgi(3) does, that handles the data
by catern 10y ago
Since the author is using cgi:
>However, this is definitely something in the crosshairs of ksql(3): forking a process, like kcgi(3) does, that handles the database I/O and communicates with the master over pipes.
If they do this, then they can just use seccomp SECCOMP_SET_MODE_STRICT, which is the first thing described in the seccomp man page and in the Wikipedia page. And is also the original/first mode of seccomp to be available.
I believe capsicum would likewise be trivial to use: You can just immediately lock things down completely. (Perhaps just cap_enter() is sufficient?)
- loeg 10y agoIf a program just needs to communicate over open sockets, cap_enter() will restrict the program from opening more sockets. But the existing fds aren't restricted. You can use caph_limit_stream(fd, CAPH_READ/CAPH_WRITE) to restrict existing sockets down to only what is needed for stdio routines.
- justincormack 10y agoSECCOMP_SET_MODE_STRICT is pretty hard to use - you cannot allocate memory for example.
- catern 10y agoI did not realize that. Given that, I was incorrect when I said that the author (or anyone) could easily use seccomp MODE_STRICT. Capsicum may still be easy to use. And seccomp-bpf is not that complex either.