[systemd-devel] SystemCallFilter

Josef Moellers jmoellers at suse.de
Tue May 28 15:10:38 UTC 2019


On 28.05.19 16:59, Lennart Poettering wrote:
> On Di, 28.05.19 14:04, Josef Moellers (jmoellers at suse.de) 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)


More information about the systemd-devel mailing list