Re: [systemd-devel] SystemCallFilter
On Di, 28.05.19 17:16, Josef Moellers (jmoell...@suse.de) wrote: > On 28.05.19 16:59, Lennart Poettering wrote: > > On Di, 28.05.19 14:04, Josef Moellers (jmoell...@suse.de) wrote: > > > >>> 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? > >> Yes. > >> > >> Linux has always been a moving target and in very many circumstances > >> this has been A Good Idea! > >> I guess I'm too much old school and try to keep to the principle of > >> least surprise. > > > > I added some docs about this to this PR: > > > > https://github.com/systemd/systemd/pull/12686 > > > > ptal! > > ... and in the section about SyscallErrorNumber, there is a duplicate > remark: > > See (see project='man-pages'>errno3 > for a full list) for a full list of error codes. > > ... unless this is somehow mangled by the documetation builder. I fixed both issues now, and submitted as new PR: https://github.com/systemd/systemd/pull/12847 (btw, please always add review comments to the github PR rather than the mailing list, it's a lot easier to keep track of for us, and remember what is cared for already and what not) ptal, thanks, Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter
On 28.05.19 16:59, Lennart Poettering wrote: > On Di, 28.05.19 14:04, Josef Moellers (jmoell...@suse.de) wrote: > >>> 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? >> Yes. >> >> Linux has always been a moving target and in very many circumstances >> this has been A Good Idea! >> I guess I'm too much old school and try to keep to the principle of >> least surprise. > > I added some docs about this to this PR: > > https://github.com/systemd/systemd/pull/12686 > > ptal! ... and in the section about SyscallErrorNumber, there is a duplicate remark: See (see errno3 for a full list) for a full list of error codes. ... unless this is somehow mangled by the documetation builder. 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter
On 28.05.19 16:59, Lennart Poettering wrote: > On Di, 28.05.19 14:04, Josef Moellers (jmoell...@suse.de) wrote: > >>> 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? >> Yes. >> >> Linux has always been a moving target and in very many circumstances >> this has been A Good Idea! >> I guess I'm too much old school and try to keep to the principle of >> least surprise. > > I added some docs about this to this PR: > > https://github.com/systemd/systemd/pull/12686 > > ptal! BTDT. Could it be that it should be the other way around? Note that various kernel system calls are defined redundantly: there are multiple system calls for executing the same operation. For example, the pidfd_send_signal() system call may be used to execute operations similar to what can be done with the older kill() system call, hence blocking the latter without the former only provides weak protection. Since new system calls are added regularly to the kernel as development progresses keeping system call whitelists comprehensive requires constant work. It is thus recommended to use blacklisting instead, which offers the benefit that new system calls are by default implicitly blocked until the whitelist is updated. Shouldn't that be "keeping system call blacklists comprehensive" and "thus recommended to use whitelisting instead," 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter
On Di, 28.05.19 14:04, Josef Moellers (jmoell...@suse.de) wrote: > > 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? > Yes. > > Linux has always been a moving target and in very many circumstances > this has been A Good Idea! > I guess I'm too much old school and try to keep to the principle of > least surprise. I added some docs about this to this PR: https://github.com/systemd/systemd/pull/12686 ptal! Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter
On 28.05.19 13:57, Lennart Poettering wrote: > On Di, 28.05.19 11:43, Josef Moellers (jmoell...@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? Yes. Linux has always been a moving target and in very many circumstances this has been A Good Idea! I guess I'm too much old school and try to keep to the principle of least surprise. Thanks for the (as ever polite!) response. 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter
On Di, 28.05.19 11:43, Josef Moellers (jmoell...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SystemCallFilter
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? Josef (*) IMHO thereby breaking The Principle Of Least Surprise. -- 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter=~@resources broken in F26/systemd233
Am 30.09.2017 um 14:38 schrieb Lennart Poettering: On Sa, 23.09.17 15:38, Reindl Harald (h.rei...@thelounge.net) wrote: with Fedroa 25 that was no problem, on F26 httpd, mysqld and so on are breaking [root@testserver:~]$ rpm -q systemd systemd-233-6.fc26.x86_64 [root@testserver:~]$ rpm -q glibc glibc-2.25-10.fc26.x86_64 @resourcesSystem calls for changing resource limits, memory and scheduling parameters (setrlimit(2), setpriority(2) Process 7320 (php71) of user 0 dumped core.#012#012Stack trace of thread 7320:#012#0 0x7fe043c14f29 __getrlimit (libc.so.6)#012#1 0x7fe043c0e771 __get_child_max (libc.so.6)#012#2 0x7fe043be5434 __sysconf (libc.so.6)#012#3 0x562a0c61062e getmaxchild (bash)#012#4 0x562a0c5c482c initialize_job_control (bash)#012#5 0x562a0c597929 shell_initialize (bash)#012#6 0x562a0c59b03d main (bash)#012#7 0x7fe043b2f50a __libc_start_main (libc.so.6)#012#8 0x562a0c59be5a _start (bash) I am pretty confident that this will fix the issue for you: https://github.com/systemd/systemd/pull/6952 only if systemd in Fedora would be proper maintained after release but then https://bugzilla.redhat.com/show_bug.cgi?id=131 would have been fixed for F25 in it's life-cycle when patches are available all the time ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemCallFilter=~@resources broken in F26/systemd233
On Sa, 23.09.17 15:38, Reindl Harald (h.rei...@thelounge.net) wrote: > with Fedroa 25 that was no problem, on F26 httpd, mysqld and so on are > breaking > > [root@testserver:~]$ rpm -q systemd > systemd-233-6.fc26.x86_64 > > [root@testserver:~]$ rpm -q glibc > glibc-2.25-10.fc26.x86_64 > > @resourcesSystem calls for changing resource limits, memory and > scheduling parameters (setrlimit(2), setpriority(2) > > Process 7320 (php71) of user 0 dumped core.#012#012Stack trace of thread > 7320:#012#0 0x7fe043c14f29 __getrlimit (libc.so.6)#012#1 > 0x7fe043c0e771 __get_child_max (libc.so.6)#012#2 0x7fe043be5434 > __sysconf (libc.so.6)#012#3 0x562a0c61062e getmaxchild (bash)#012#4 > 0x562a0c5c482c initialize_job_control (bash)#012#5 0x562a0c597929 > shell_initialize (bash)#012#6 0x562a0c59b03d main (bash)#012#7 > 0x7fe043b2f50a __libc_start_main (libc.so.6)#012#8 0x562a0c59be5a > _start (bash) I am pretty confident that this will fix the issue for you: https://github.com/systemd/systemd/pull/6952 Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] SystemCallFilter=~@resources broken in F26/systemd233
with Fedroa 25 that was no problem, on F26 httpd, mysqld and so on are breaking [root@testserver:~]$ rpm -q systemd systemd-233-6.fc26.x86_64 [root@testserver:~]$ rpm -q glibc glibc-2.25-10.fc26.x86_64 @resourcesSystem calls for changing resource limits, memory and scheduling parameters (setrlimit(2), setpriority(2) Process 7320 (php71) of user 0 dumped core.#012#012Stack trace of thread 7320:#012#0 0x7fe043c14f29 __getrlimit (libc.so.6)#012#1 0x7fe043c0e771 __get_child_max (libc.so.6)#012#2 0x7fe043be5434 __sysconf (libc.so.6)#012#3 0x562a0c61062e getmaxchild (bash)#012#4 0x562a0c5c482c initialize_job_control (bash)#012#5 0x562a0c597929 shell_initialize (bash)#012#6 0x562a0c59b03d main (bash)#012#7 0x7fe043b2f50a __libc_start_main (libc.so.6)#012#8 0x562a0c59be5a _start (bash) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
