On Wed, 27 Jan 2016, Michael Biebl wrote:
Hi everyone,
I'd like to make use of some of the systemd hardening features [0] in
the Debian rsyslog package.
I eventually want those changes to go upstream though, so I'm asking
for feedback here.
This is what I currently have in mind:
[Service]
ProtectSystem=full
what does this do?
ProtectHome=yes
PrivateTmp=yes
If these prevent writes (or reads) to home directories or tmp, they should be ok
most of the time. But rsyslog has lots of features that pull in files or output
to arbitrary places configured by the admin. If you do something like this,
please add comments in the defau;t rsyslog.conf file (and seriously think of
adding them to a customized config file) warning the admin that if they need to
access X they will need to change the systemd config file.
We have enough trouble with SELinux and AppArmor already.
CapabilityBoundingSet=CAP_SYSLOG CAP_NET_BIND_SERVICE
What potentially could cause problems is the limitation of the
capabilties via CapabilityBoundingSet [1].
Does anyone know, what capabilities [2] rsyslog needs beyond
CAP_SYSLOG and CAP_NET_BIND_SERVICE if you want to make use of all its
features?
mmexternal, omprog, output channels can run arbitrary programs on the system, so
yes, full use of features could require anything :-)
mmnormalize commonly pulls in rulesets from whereever the admin set them up
lookup tables can read in data from files wherever the admin sets them up. These
are designed to be updated by other programs and re-loaded into rsyslog on the
fly (triggered by a specific log message)
If you are going to start playing around with capabilities, then set the
capability to let rsyslog bind to a low port without being root and set the
permissions on the log directories appropriately and run rsyslog as non-root
(not privdrop to non-root, non-root from the beginning)
In any case, this is a good option to have
While you are working on custom systemd configs, can we also setup a couple
options for the systemd/rsyslog interaction?
Push mode:
journald gets the log and delviers it with no metadata to rsyslog
Push mode with metadata:
journald gets the log and delviers it with forged metadata to rsyslog
Polling mode:
journald gets the log and rsyslog fetches it from journald with metadata via
imjournal.
Bupass mode:
journald doesn't grab /dev/log, allowing rsyslog to get the data directly
from the app. This allows rsyslog to grab the metadata directly
JSON delivery:
carry a patch to journald to have it deliver logs to rsyslog with metadata
in JSON (note that LP has said that he will refuse to accept a patch that does
this, so it's something the distros will have to carry. I have this bookmarked
on my office machine and can forward the link later today)
I would also point out the issue of journald grabbing audit logs and the flood
of messages that creates. It's a good option to have, but there needs to be an
easy to find option to disable it, especially since traditionally this has not
been part of the log flow and is high volume.
Are other distros interested in shipping such a more restrictive configuration?
I don't run anything in production with systemd yet, but since Ubuntu 16.04 is
going to include it, I was expecting to have to fight some of this and can do
tests on my laptops with these options.
David Lang
Regards,
Michael
[0] http://0pointer.de/blog/projects/security.html
[1]
http://www.freedesktop.org/software/systemd/man/systemd.exec.html#CapabilityBoundingSet=
[2] http://man7.org/linux/man-pages/man7/capabilities.7.html
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
