Re: chroot'ed environment?

[smb () research att com (smb () research att com)]

         Could someone give me a hint on what security it buys to do a
         chroot before servicing a request from a network daemon? I
         guess it depends on what the attacker is able to find in the
         chrooted environment, if he can import programs, ...

Good question.  Chroot is a very strong (though not perfect) mechanism
for restricting access to files.  As such, it's very useful for things
like ftp and gopher servers, and for some uses of http servers.  It
is not nearly as strong against programs that are executing in the
chroot area, since other resources belonging to the machine are shared,
notably its network identity.  That's why it doesn't work as well for
httpd -- most such servers want to execute perl scripts and other
user-written goo, and chroot isn't a strong defense in this case
(though it's certainly better than nothing).

         Also, if it is not too off-topic, what would be the best way
         to allow syslogs after a chroot, if the syslog daemon uses
         unix datagram sockets, that dont survive the chroot call?

There are several approaches that have been used; all have their
limitations.  You could change the syslog subroutine to use the UDP
port.  You could use a UNIX stream socket.  Or there's a hack that
works on some systems, if you need only one chroot'ed syslogd...

Make /dev/syslog a symlink to the real location of the socket, perhaps
/usr/ftp/dev/syslog.  Fire up syslogd with the (often undocumented)
-p option, telling it the real location.  Ordinary programs trying to
send to /dev/syslog will follow the symlink.  Ftpd will have its own
/dev/syslog which is the real thing.  And syslogd will get both of them.

Note, of course, that this doesn't work if you need the same ability
in ftpd and httpd, and they have separate chroot areas.