Hi all, So, let me use this reply as a warp-up of my thoughts. Basically, I agree to HKS argument. 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.
But, of course, it all depends on the effort required. And more security is always welcome. So I took time out today to think about the options and experiment a bit. I came to the conclusion that some improvement can probably be made in short time. I experimentally implemented a new $PrivDropToUser config directive, which basically issues a setuid() call with the user in question. It is far from being bullet-proof and will never be totally save without architecture changes. But I think it still can considerably improve security and when we can achieve this with a few hours of work, it's probably worth the effort (a bit more work would improve its security, but I don't do this unless I get feedback it makes sense at all). HOWEVER, there are also some things that simply don't work out. For example, imklog reads the proc file system under Linux and, even though it is opened as root, these reads fail after dropping to another user. There may be other issues, I have not further investigated that. I have created a bugzilla enhancement request for it: http://bugzilla.adiscon.com/show_bug.cgi?id=105 You may want to subscribe to that bug for updates. The experimental code is available here: http://git.adiscon.com/?p=rsyslog.git;a=shortlog;h=refs/heads/droppriv I would appreciate feedback a) on the general issue b) on the experimental code itself Many thanks, Rainer On Tue, 2008-11-18 at 17:29 -0500, (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. > > Of course, all of the above would be just fine with me. > > -HKS > _______________________________________________ > 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
