On Tue, 18 Nov 2008, Don Jackson wrote: > On Nov 18, 2008, at 1:10 PM, [EMAIL PROTECTED] wrote: > >> On Tue, 18 Nov 2008, Don Jackson wrote: >> >> >>> and also chroot to a directory on that partition, so if the rsyslogd >>> process itself is compromised, >>> it can't do other damage. >> >> that gives you protection if you are receiving logs from the >> network, but >> if you are receiving logs from /dev/log (local logs) you can't go >> into a >> chroot effectivly > > Protecting the "server" from attacks from networked clients seems like > a good idea. > > To answer your later question, I use OpenBSD a lot. > Here is how the stock syslogd on OpenBSD provides a /dev/log for each > chrooted app:
the issue isn't providing a /dev/log for each chroot app, that can be done easily from a syslogd that's not in the chroot by opening additional pipes, the problem is that if the syslogd itself is inside a chroot it cannot open anything _outside_ of that chroot, so it can't provide the /dev/log device for the main system. and you don't want to open that before you go into the chroot becouse one of the ways to break out of a chroot involves having a file handle open to something outside of the chroot. >>> There must be a way to have a daemon run as a non-root user, and also >>> to open ports < 1024. >>> This seems to be done all the time on *bsd machines: >> >> the POSIX standard still calls for ports < 1024 to require root to >> bind to >> them, different systems have different ways to be non-compliant with >> the >> standard and let you do so anyway. what OS are you using? > > Sorry, I was not being clear nor accurate here. > > What I meant to say was, OK, start up as root, open the resources you > need, and then chroot, both to change your userid to something that is > non-root ( user _rsyslog ?), and also > to put rsyslog into a restricted subset file system. Could you not > open up the network ports needed, and also /dev/log (for the benefit > of apps running on that machine that will > write there?) before the call to chroot? changing the userid will work, doing a chroot will not. > If not, it looks like what syslogd on OpenBSD does is separate itself > into to processes, the main process runs as root, and then it spawns a > child that runs as user _syslogd, > it is this child process that listens to log sockets, while the parent > process gives the child access to write log files. rsyslog is multi-threaded, not multi-process. all the threads have access to everything that any one thread has access to, so it wouldn't help to seperate things out without serious surgery to rsyslog. you could do something like have one copy of rsyslog running inside a chroot, and another one running outside the chroot with the one outside the chroot not listening to the network but forwarding everything it receives to the one inside the chroot. this may require a little bit of work to make work (depending on how outbound network connections are made from rsyslog) David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
