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:
>> We just had an issue with a partner who tried to filter out the
>> system call:
>> . This may, in general, not be a very clever idea because how is one
>> load a shared library to start with, but this example has revealed
>> something problematic ...
>> 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
>> "open" system call would be used, which it doesn't any more. It uses
>> "openat" system call instead (*).
> AFAIK, glibc hardly ever uses open(2) any more, and has been doing so
> 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
>> 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.
>> I regard "SystemCallFilter" as a security measure and if one cannot
>> 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!
SUSE Linux GmbH
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
More information about the systemd-devel