sorry to reply to the earlier post, I managed to delete the most recent
messages, or I would reply to those directly
On Wed, 27 Jan 2016, Michael Biebl wrote:
[Service]
ProtectSystem=full
This seems reasonable
ProtectHome=yes
This seems reasonable. with the one caviot that I suspect a lot of people will
do experimentation with rulesets in /root (I know i did for example), so a
comment explaing these things should be added to the default config.
PrivateTmp=yes
what use of /tmp does rsyslog make? If none, can we just block access rather
than going to all the effort of creating a custom version?
This can also affect things that rsyslog runs through omprog/etc. so
documentation is needed.
Along similar lines, if rsyslog isn't creating /dev/log, can access to devices
be disabled (PrivateDevices)?
But the bigger question I would ask, is if the overhead/complexity of setting
this up is really worthwhile if the system has SELinux or AppArmor on it
restricting access to these things?
What is the overhead of writing through a filesystem namespace?
How many debugging questions is this going to generate because people can't
figure out why permissions say they should be able to do something, but they
can't? This is one more way that running rsyslog from the command line as root
differs from running it as a service.
If we are going to accept the overhead of a filesystem namespace, then we should
use the ReasWriteDirectories, ReadOnlyDirectories, etc mechanism (The AppArmor
list of directories needed would be a good start for this)
For that matter, can we map out what system calls are made by rsyslog and it's
included modules in an automated fashion?
For capabilities, and possibly for some of these others, we will find as we try
to lock things down that different modules have different requirements. We
should try to figure out a way to document what module needs what (including the
open-ended ones), and see if we can have a rsyslog.lockdown tool that can parse
the rsyslog.conf and figure out what modules are in use and create a very tight
config that is tailored to what's in use. One of the things that I really hate
about SELinux is that while it's able to be used in an extremely secure fashion,
actually doing so is so hard that almost nobody does, and the distro defaults
have to be so open (to let all of the optional modules work), that the amount of
security that it ends up adding to the system is very questionable.
There is value in adding layers of protection, there is also cost. It's good for
this to be an option and have a standard starting point for everyone to use. We
just need to be very clear on the documentation and troubleshooting stuff.
We don't want to end up in the SELinux trap where it's so hard to deal with that
the standard answer is 'turn it off'.
David Lang
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?
Are other distros interested in shipping such a more restrictive configuration?
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.
