2008/11/19 Rainer Gerhards <[EMAIL PROTECTED]>: > 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.
/dev/klog could be made accessible via an ACL or a separate group. (e.g. the init script of the distro could chgrp or setfacl /dev/klog). Distros will also have to make sure, that the rsyslog daemon has write access to /var/log (or wherever they put their log files by default, but that is easily solvable too). More tricky will be the already mentioned opening of privileged ports I think. Cheers, Michael -- 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
