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) _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel