[systemd-devel] SystemCallFilter

Josef Moellers jmoellers at suse.de
Tue May 28 11:42:19 UTC 2019


On 28.05.19 12:25, Martin Wilck wrote:
> 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.

Yes, I found out the hard way ... testing and testing until i ran the
script through strace and found that fopen() doesn't use "open" any more :-(

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

I agree. The suggestion was only mode for completeness.

>> * 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.

Yes.

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

It is indeed implemented that way!

Thanks,

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