nspawn seccomp improvements #6798
Conversation
…r_set() The function doesn't actually use the parameter, hence let's drop it.
Let's add a new helper function seccomp_add_syscall_filter_item() that contains the inner loop code of seccomp_add_syscall_filter_set(). This helper function we can then export and make use of elsewhere.
Let's unify a bit of the code here.
…s to the existing syscall groups Let's shorten the table, now that we are hooked up to the syscall group system.
| <command>syscall-filter</command> command of <citerefentry | ||
| project='man-pages'><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>). Passed | ||
| system calls will be permitted. The list may optionally be prefixed by <literal>~</literal>, in which case all | ||
| listed system calls are prohibited. If this command line option is used multiple times the configured lists are |
There was a problem hiding this comment.
thanks, fixed in a new force pushed version
138c53e to
4cf0a70
Compare
Now that we have ported nspawn's seccomp code to the generic code in seccomp-util, let's extend it to support whitelisting and blacklisting of specific additional syscalls. This uses similar syntax as PID1's support for system call filtering, but in contrast to that always implements a blacklist (and not a whitelist), as we prepopulate the filter with a blacklist, and the unit's system call filter logic does not come with anything prepopulated. (Later on we might actually want to invert the logic here, and whitelist rather than blacklist things, but at this point let's not do that. In case we switch this over later, the syscall add/remove logic of this commit should be compatible conceptually.) Fixes: systemd#5163 Replaces: systemd#5944
4cf0a70 to
960e456
Compare
|
btw, @robertgzr, @alban, @iaguis, a proper review would be very welcome, so that we can merge this, hint hint ;-) |
|
Just a question: |
|
@robertgzr not sure i grok the question, but do note that the way this is implemented now the "exclude" strv is not just applied to the "top-level" list, but also individually to each syscall list that syscall groups map to. |
|
@poettering I guess it's just a question of where you put more code^^ in nspawn or in seccomp-util, that's what I was asking. |
well, that really depends. Usually as long as something only has a single consumer indeed the best place is to do it in the consumer, not in the generic library code. But then again, it's a blurry line, and sometimes things are genericly useful enough to do them in the generic library code... |
|
thanks for the review! |
A number of clean-ups for the nspawn seccomp code, all leading up to a fix for #5163. This includes an alternative (but more comprehensive) to #5944 which appears to have stalled.