Am 11.10.23 um 23:48 schrieb Robert Edmonds:
Michael Biebl wrote:While the attempt is to secure the default configuration of rsyslog, I do not want to restrict it so much that it becomes unusable. If you think, that one of those directives could cause issues with commonly used setups, please let me know, so I can adjust the configuration. Looking forward to your feedback.Maybe also add `RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX`?
Thanks for the suggestion, seems reasonable. Will include it in the next upload
I see the rsyslog package is compiled without capng support: --enable-libcap-ng Enable dropping capabilities to only the necessary set [default=no] With the libcap-ng dependency rsyslog can apparently perform capability privilege dropping at some point during startup: https://sources.debian.org/src/rsyslog/8.2308.0-1/tools/rsyslogd.c/#L1584-L1664 I seem to recall that capability dropping requires additional privileges, though (CAP_SETPCAP?). Is this code in rsyslog maybe redundant if the process starts up with the already reduced set of capabilities and that's the rationale for not building the package with --enable-libcap-ng? I guess if that's the case then there aren't any capabilities that are needed by rsyslog only briefly at startup that can be dropped by the daemon itself?
Since the builtin capability dropping in rsyslog via libcap-ng is rather static (it doesn't depend on the actual configuration or the modules loaded), I didn't see any benefit to go this way, which would justify the additional libcap-ng dependency.
One significant benefit of doing it via rsyslog.service is that you can easily tweak the list of capabilities by editing rsyslog.service or creating a drop-in, something you couldn't do if rsyslog was built with --enable-libcap-ng (you can only turn it off completely via rsyslog.conf).
Description: OpenPGP digital signature