On Wed, 27 Jan 2016, Michael Biebl wrote:
2016-01-27 16:13 GMT+01:00 David Lang <[email protected]>:
On Wed, 27 Jan 2016, Michael Biebl wrote:
[Service]
ProtectSystem=full
what does this do?
http://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=
ProtectHome=yes
http://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome=
PrivateTmp=yes
http://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=
thanks, I'll look at these later.
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 :-)
Hm, true. But that's a very specialised setup.
I wonder whether it makes sense to concentrate on the common case and
include some NEWS entry telling people how they could turn those
restrictions off.
NEWS entries aren't found unless you know to look for them. It would be better
to include a commented-out example in the rsyslog.conf with a note saying what
else needs to be done to make these work.
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)
similarly, examples or comments in the rsyslog.conf that X permissions (SELinux,
AppArmor, systemd configs) restrict things to only being in X places would be
good.
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)
I was under the impression, that running under a different uid/gid was
still problematic.
what's problematic is starting with one uid/gid and dropping privilges to
another. It's too easy for something to be possible at atartup under the initial
uid/gid that can't be repeated later after privileges are dropped. Since just
about everything that happens at startup can happen at other times, this causes
problems.
IF the original user that rsyslog starts as has the ability to do everything
that it needs, it shouldn't have to be root. But 'do everything that it needs'
commonly includes the need to listen to privileged ports, which requires
capabilities if non-root. mmudpspoof would also need raw packet creation
Taking away capabilities via the systemd directives looked like a good
middle ground to me.
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
That's already possible today. I thought I already posted how to do
this, but apparently I didn't
I've had it told to me in lwn.net comments, but when I go back and try to find
it I have had trouble. We need to add sections to the Rsyslog docs about
interactions with SELinux, AppArmor and systemd to contain such details.
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'm concerned shipping such a patch downstream and deviating from upstream.
I understand your concern, but it is such a useful option, and it should be a
short patch (some config setting, plus a subroutine to output as JSON, it
shouldn't even need a JSON library, hand-crafting the output format should be
easy enough)
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.
I think this can be disabled via audit=0 on he kernel command line.
But I might be misunderstanding you.
I'll dig up and post the systemd thread later today. ideally you don't want to
disable all auditing, just disable pulling it into the logstream and leaving it
as a separate log the way it's been for a long time.
David Lang
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.
I'd be very interested in further feedback, before turning this on.
_______________________________________________
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.
