On Wed, Jan 27, 2016 at 10:33 AM, Michael Biebl <[email protected]> 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= > > > 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? > Have you talked to the Fedora folks about these changes as well? These seem pretty interesting and worth while. > > > > > > 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. > How would these options be delivered? > > > 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. > _______________________________________________ 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.
