2016-01-27 16:13 GMT+01:00 David Lang <da...@lang.hm>: > 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= > 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. > 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) I was under the impression, that running under a different uid/gid was still problematic. 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 > 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 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. >> 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. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? _______________________________________________ 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.
