[systemd-devel] SystemCallFilter

[Lennart Poettering]

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?

Lennart

--
Lennart Poettering, Berlin