Hi Don, thanks for your careful thoughts. I would also appreciate if you could try out the experimental branch, but on the other hand I think I will be able to create a regular devel branch based on some of the discussion this week.
On Sat, 2008-11-22 at 12:34 -0800, Don Jackson wrote: > On Nov 21, 2008, at 4:11 AM, Jan-Frode Myklebust wrote: > > > For my usage, I need two modes of operation for syslog daemons. > > > > 1 - local syslog. Requires privileges to on local devices (/dev/ > > log, > > /dev/klogd or similar), write to local log-files, and send to > > remote log server. > > > > 2 - central log server. Only listen on the needed network ports > > (514/udp/tcp), and write to local log files (possibly also send > > to other remote log servers). > > > > For #1 I think it's OK not being able to chroot, keep more privileges, > > etc., as the attacks against it will mostly be from local processes. > > > > #2 needs to be *very* openly available on the network ports, since all > > my servers needs to send logs to it. #2 will also be holding a lot > > more > > sensitive data than #1, so I think this server needs to be protected > > as > > much as possible. If chroot'ing, or dropping privileges prevents it > > from > > reading from local /proc og /dev, I think that wouldn't matter much. > > One > > could always run two instances on these few central servers, i.e. #1 > > sending to #2. > > Yes, your two modes as defined above are exactly how I run syslog, and > I think the distinction between the two use cases > local-syslog and central-log-server is very useful and important in > this discussion. Even further, I think this could be different (but compatible) use cases in a to-be-written rsyslog security doc. > > And I agree with your prioritization of security between the two > modes, the local-syslog does not need to open a network port > to listen for log messages, and so it is only at risk from other > processes on the same box. > > The central-log-server does need to open and read a network port, and > needs to be open to lots of devices on the network, and thus it is at > the most risk. > That is the version that most needs privilege separation and chroot. > And I agree that the server that runs the central-log-server could > also run an instance of the local-syslog, the local-syslog would > handle /dev/log on that machine, and forward msgs to be centrally > logged onto the central-log-server running on the same machine. > > From another sub-thread: > > > On Nov 19, 2008, at 4:32 AM, Rainer Gerhards wrote: > > > Yes, the traditional HUP behavior is simply incompatible with dropping > > privileges. But I assume that someone who configures rsyslogd in > > such a > > way knows what he does and thus changes config-reload scripts away > > from > > HUP to a real reload. > > I am not sure about the details of the implementation, but named on > OpenBSD supports privilege separation, and it provides > some of your HUP functionality, although possibly in different ways: [snip] It would be too much info to go in full detail, but HUP is ugly and it is a full restart. I'd like to phase out that mode, but will probably need to keep it for "admin compatibility". Anyhow, I do not see any issue if, in a secure system, HUP does not work as a full restart. (One way to make it work would be to have a master running all the time and the actual rsyslogd being a child where the parent handles HUP and restarts the "real" rsyslogd - but I don't like to make it so compliated "just" to satisfy old habits... [who likes this can always contribute the code ;)]). > On yet another sub-thread: > > On Nov 19, 2008, at 4:46 AM, Rainer Gerhards wrote: > > I also agree to David Lang's argument that some > > degree of design change would be necessary to get the requested > > features > > done 100% correct. > > It is generally difficult to add security ex post facto, and the more > code that is written prior to the implementation of those design > changes will tend to increase the difficultly/cost of that > implementation. That's totally right, and rsyslog is a good example. First of all it is important to remember that it was not designed from scratch. We forked it off from sysklogd. And while almost no sysklogd code remains today, we had a long chain of design decisions which were based on the need to keep compatible with sysklogd. If you traverse that chain, you'll see why some things are as they are. The security approach was not to be worse than sysklogd and better where possible, but there always was a strong focus on deliverving something. You may argue that it is foolish not doing the "right thing" right from the beginning. My view is that we live in an imperfect (and risky) world and it is important to get some things done. So I don't want to limit myself in using a better solution because that better solution is not better in some aspect than the previous solution, which I would be using otherwise. In somewhat more formal words. If sysklogd's number if features is F_sysklogd and it's probably of security breach is S_sysklog and the exact same concepts for rsyslog are F_rsyslog and S_rsyslog, then I don't see any reason not to use rsyslog over sysklogd if F_rsyslog > F_sysklogd and R_rsyslog <= R_sysklogd. In even other words, if I would not use rsyslog because it is not as secure as sysklogd, I would ditch it without getting any benefit and I would also not get the benefits from the new features it offers. One may of course argue that rsyslog's addition feature inherently increase the risk of using it, in which case S_rsyslog < S_sysklogd. The only argument I have against this is that you can disable most of these new features so that you can limit the potential risk exposure. In any case, you are right that the ultimate goal should be to keep as secure *as possible* and this is why I immediately followed up on your questions. But I think it is still very important to not let security be a show stopper in a case if it is not worsened. I think if I had started the rsyslog project with a totally secure design, rsyslog would be obsolete by now because anybody would already have moved over to syslog-ng and no other solution would have a chance to rise. I am not saying that syslog-ng is a bad project, nor am I saying it is less secure than rsyslog (right now, it probably is more secure). But a world with just syslog-ng (or one with just rsyslog!) is a monoculture a monoculture has inherent and very large security risk. I sincerely believe (bash me) that Windows is *not* bad software (or at least not worse than Linux). It "just" is (well, "was" ;)) a monoculture and that lead to much more interest in attacking it. The financial benefit of attacking it was much greater than the benefit of attacking Linux. If you look from that angle (and I do), you'll find that a world with a not-so-secure rsyslog AND syslog-ng is more secure than a world with a totally-secure rsyslog (that nobody uses) and and always-present syslog-ng (being a monoculture on the vast majority of systems). So less security in a "subsystem" brought more security to the overall picture. Still, I strongly favor an as-secure-as possible rsyslog, but I need to abide to the constraints given (and with the financial crises and loss of sponsorship these constraints for the rsyslog project unfortunately have not become more permitting...). > > On Nov 18, 2008, at 2:29 PM, (private) HKS wrote: > > FWIW, while I believe this discussion is relevant and the security > > changes proposed are important, I don't see this as a high priority > > feature. The scripting language/syntax, greater performance, continued > > stability enhancements, and true RELP support are all far more > > important. As far as security goes, I would much rather see two-way > > host authentication than a chroot/unprivilieged framework implemented. > > I don't know what the author's goals for rsyslog are, so it is > difficult to prioritize. > > What *I* would like rsyslog to be is the clear choice to replace > syslog on all the machines in my network, on all the OSes I care about > (OpenBSD, Solaris, FreeBSD, etc), > basically "total world domination of the syslog space" :-) as said above, "total world dominition" is sweet fruit, but it has a big risk associated with it... > > I would ask Ranier and others here to reflect on the need/importance > of security vis-a-vis their ultimate goals for rsyslog, and if > security is going to be important (I think it is crucial, but you need > to come to that conclusion yourself), and the cost of implementing > security design changes is going to increase over time, to consider > making those design changes sooner rather than later. I hope I outlined these thoughts above. Please keep asking/suggesting. My mind is always open to change and I like good arguments ;) Rainer > > In closing, I am learning a lot and enjoying the thoughtful and > patient responses to my original email on this topic, kudos to the > rsyslog community, it is a welcome change from some other mailing > lists :-) > > Best regards, > > Don > > > > > > > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
