Re: [systemd-devel] Seccomp allow/log action
On 7/8/20 2:31 PM, Topi Miettinen wrote: On 8.7.2020 17.47, Chris PeBenito wrote: I would like to implement a unit option that would make the seccomp action SCMP_ACT_LOG so that I can test SystemCallFilter settings without killing the services, like SELinux permissive mode. I was reading this github issue about seccomp actions from last year: https://github.com/systemd/systemd/issues/11967 While it mentioned other actions, it was mainly about changing the kill action to kill the process rather than just the offending thread. There wasn't a solid conclusion about how allow/log actions would work in terms of unit options. I figure one option is adding a new option like SystemCallFillterAllow=bool that would conflict with SystemCallFilterErrno. If true it would set SCMP_ACT_LOG for the action. Having a setting for SCMP_ACT_ALLOW seems redundant since it's equivalent to commenting out the SystemCallFilter option since there's no logging. I think it would be more flexible to extend the error code return per system call, like SystemCallFilter=gettimeofday:LOG Yes, that provides much more granularity but is it necessary to support that level of granularity in systemd? Fine-grained system call logging is available in the audit subsystem and is much more flexible. For global error action, I'd propose SystemCallErrorNumber= to be superseded by more generic SystemCallErrorAction= KILL | LOG | errno code -- Chris PeBenito ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Seccomp allow/log action
I would like to implement a unit option that would make the seccomp action SCMP_ACT_LOG so that I can test SystemCallFilter settings without killing the services, like SELinux permissive mode. I was reading this github issue about seccomp actions from last year: https://github.com/systemd/systemd/issues/11967 While it mentioned other actions, it was mainly about changing the kill action to kill the process rather than just the offending thread. There wasn't a solid conclusion about how allow/log actions would work in terms of unit options. I figure one option is adding a new option like SystemCallFillterAllow=bool that would conflict with SystemCallFilterErrno. If true it would set SCMP_ACT_LOG for the action. Having a setting for SCMP_ACT_ALLOW seems redundant since it's equivalent to commenting out the SystemCallFilter option since there's no logging. Is there a preference to how the config options would work? -- Chris PeBenito ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Seccomp filters from file
On 6/23/20 10:57 AM, Lennart Poettering wrote: On Di, 23.06.20 09:41, Chris PeBenito (chpeb...@linux.microsoft.com) wrote: I've got some challenges using systemd's seccomp support because it conflicts with the way my system is managed. I need to manage the seccomp SystemCallFilter lists in a central location (single directory) so that they can be updated independently of the packages and portable services on my systems. Would there be any objections to a patch that would add a new unit option for loading the system call filter list out of a specified file? seccomp is still only supports plain bpf, not ebpf iirc. For some of the ebpf uses we noawadays support that you can upload your filter yourself and then make systemd use it: IPIngressFilterPath=/IPEgressFilterPath=. As soon as seccomp supports ebpf natively we could expose the same mechanism also for system call filtering, but until that happens I don't see any smart future-proof way to provide an interface for integrating your own filters with systemd. I don't understand your concern; can you clarify? Is it a concern about the kernel ABI stability for seccomp? -- Chris PeBenito ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] Seccomp filters from file
I've got some challenges using systemd's seccomp support because it conflicts with the way my system is managed. I need to manage the seccomp SystemCallFilter lists in a central location (single directory) so that they can be updated independently of the packages and portable services on my systems. Would there be any objections to a patch that would add a new unit option for loading the system call filter list out of a specified file? -- Chris PeBenito ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
