Very Computer

by **Stefan Monnie** » Fri, 19 Nov 1999 04:00:00

Is there somewhere a summary of all the little pitfalls one should
look for when setting up chrooted daemons ?

What is the standard way to have the chrooted daemon talk to syslog,
for example ?

How about other "external" files/sockets such as /var/run/ndc or
/var/run/<foo>.pid, etc ... ?

Are there other things to watch out for ?

Stefan

by **Jefferson Ogat** » Fri, 19 Nov 1999 04:00:00

> Is there somewhere a summary of all the little pitfalls one should
> look for when setting up chrooted daemons ?

> What is the standard way to have the chrooted daemon talk to syslog,
> for example ?

Depends on the OS. If you're running Linux or FreeBSD, for example, the
syslogd supports commandline options to listen on up to 19 additional
Unix-domain sockets, so you can drop a /dev/log in a lot of chroot
hierarchies. Otherwise, you can run multiple chrooted forwarding syslogd
processes, but it's a large pain.

Quote:> How about other "external" files/sockets such as /var/run/ndc or
> /var/run/<foo>.pid, etc ... ?

Just create equivalent directories in your chroot hierarchy. Teach your
init scripts where to find the real files. You might get by with soft
links in the real /var/run.

Quote:> Are there other things to watch out for ?

Learn to use strace or truss or par, whatever your system call trace
program is, to watch for library and file opens. If you have ldd it's
very useful but it doesn't catch everything.

Don't put setuid programs in chroot hierarchies if you can avoid it.
Don't run daemons as root in chroot hierarchies if you can avoid it. Try
to run daemons that chroot and drop privileges after binding their local
endpoint, e.g the named that ships with Red Hat and FreeBSD, among
others. If someone can get root in a chroot hierarchy he may be able to
break out. Don't put users with elevated privileges in the chroot
/etc/passwd and /etc/group if you can avoid it.

If you're running an OS that supports loopback mounts, e.g. BSD,
Solaris, you can remount large sections of your chroot hierarchy
read-only from other points in the filesystem. If your OS supports it,
you can also turn off setuid and device handling on the loopback mounts.
Thus you can build a generic library/binary executable hierarchy which
you loopback mount to all your chroot hierarchies. This has the dramatic
advantage that when you apply patches to your OS you don't have to go in
and update 15 library files in six different chroot hierarchies. Just do
it once in your generic hierarchy.

Quote:> Stefan

--

Very Computer

chrooted daemons howto

chrooted daemons howto

chrooted daemons howto