Re: SystemCallFilter

[Martin Wilck <mwilck@xxxxxxx>]

On Tue, 2019-05-28 at 11:43 +0200, Josef Moellers 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 (*).

AFAIK, glibc hardly ever uses open(2) any more, and has been doing so
fo
r some time.

> 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?

That looks wrong to me. Some people *might* want to filter open(2)
only, and would be even more surprised than you are now if this
would implicitly filter out openat(2) as well.

> * introduce a new group "@open" which filters both?

Fair, but then there are lots of XYat() syscalls which would need
to be treated the same way.

> I regard "SystemCallFilter" as a security measure and if one cannot
> rely
> on mechanisms any more, what good is such a feature?

Have you seen this? https://lwn.net/Articles/738694/
IMO this is a question related to seccomp design; "SystemCallFilter"
is just a convenient helper for using seccomp.

Cheers,
Martin


_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel