On 28.05.19 16:59, Lennart Poettering wrote: > On Di, 28.05.19 14:04, Josef Moellers (jmoellers@xxxxxxx) wrote: > >>> Regarding the syscall groupings: yes, the groups exist precisely to >>> improve cases like this. That said, I think we should be careful not >>> have an inflation of groups, and we should ask twice whether a group >>> is really desirable before adding it. I'd argue in the open/openat >>> case the case is not strong enough though: writing a filter >>> blacklisting those is very difficult, as it means you cannot run >>> programs with dynamic libraries (as loading those requires >>> open/openat), which hence limits the applications very much and >>> restricts its use to very few, very technical cases. In those case I >>> have the suspicion the writer of the filters needs to know in very >>> much detail what the semantics are anyway, and he hence isn't helped >>> too much by this group. >>> >>> Note that the @file-system group already includes both, so maybe >>> that's a more adequate solution? (not usable for blacklisting though, >>> only for whirelisting, realistically). >>> >>> Hence, I would argue this is a documentation issue, not a bug >>> really... Does that make sense? >> Yes. >> >> Linux has always been a moving target and in very many circumstances >> this has been A Good Idea! >> I guess I'm too much old school and try to keep to the principle of >> least surprise. > > I added some docs about this to this PR: > > https://github.com/systemd/systemd/pull/12686 > > ptal! BTDT. Could it be that it should be the other way around? <para>Note that various kernel system calls are defined redundantly: there are multiple system calls for executing the same operation. For example, the <function>pidfd_send_signal()</function> system call may be used to execute operations similar to what can be done with the older <function>kill()</function> system call, hence blocking the latter without the former only provides weak protection. Since new system calls are added regularly to the kernel as development progresses keeping system call whitelists comprehensive requires constant work. It is thus recommended to use blacklisting instead, which offers the benefit that new system calls are by default implicitly blocked until the whitelist is updated.</para> Shouldn't that be "keeping system call blacklists comprehensive" and "thus recommended to use whitelisting instead," Josef -- SUSE Linux GmbH Maxfeldstrasse 5 90409 Nuernberg Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel