[systemd-devel] SystemCallFilter

[Josef Moellers]

On 28.05.19 13:57, Lennart Poettering wrote:
> On Di, 28.05.19 11:43, Josef Moellers (jmoellers at suse.de) wrote:
> 
>> Hi,
>>
>> We just had an issue with a partner who tried to filter out the "open"
>> system call:
>>
>> . This may, in general, not be a very clever idea because how is one to
>> load a shared library to start with, but this example has revealed
>> something problematic ...
>> 	SystemCallFilter=~open
>> The problem the partner had was that the filter just didn't work. No
>> matter what he tried, the test program ran to completion.
>>
>> It took us some time to figure out what caused this:
>> The test program relied on the fact that when it called open(), that the
>> "open" system call would be used, which it doesn't any more. It uses the
>> "openat" system call instead (*).
>> Now it appears that this change is deliberate and so my question is what
>> to do about these cases.
>> Should one
>> * also filter out "openat" if only "open" is required?
>> * introduce a new group "@open" which filters both?
>>
>> I regard "SystemCallFilter" as a security measure and if one cannot rely
>> on mechanisms any more, what good is such a feature?
> 
> This is a general problem: as the kernel is developed, new system
> calls are added, and very often they provide redundat mechanisms to
> earlier system calls. Thiis is the case with openat() vs. open(), and
> for example very recently with pidfd_send_signal() vs. kill(). We will
> always play catch-up with that unfortunately, it's an inherent problem
> of the system call interface and applying blacklist filters to it, and
> we are not going to solve that, I fear.
> 
> I think we should add docs about this case, underlining two things:
> 
> 1. first of all: whitelist, don't blacklist! If so, all new system
>    calls are blocked by default, and thus the problem goes away.
> 
> 2. secondly: we should clarify that some system calls can be
>    circumvented by using others, and hence people must be ready for
>    that and not assume blacklists could ever be future-proof.
> 
> 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.

Thanks for the (as ever polite!) response.

Josef
-- 
SUSE Linux GmbH
Maxfeldstrasse 5
90409 Nuernberg
Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)