On Sun, Apr 22, 2001 at 08:50:45PM +1200, nic@plumtree.co.nz wrote: > > > Just two questions: > > i) Is there any reason why you decided to include the named binaries in > the chroot? you have to have at least named-xfer. > There is no need for them to be there, since named does the chroot > internal. In fact this might represent a security hole. yes there is. > Consider some manages to break named and get access to the chroot > enviroment. The manage to upload a trojaned vesion of the named binary > somehow. The server boots and the system is wide open. not if you setup the chroot jail with correct permissions. ie NOT chown -R named.named /var/named. the ONLY part of the chroot jail that should be writable by named is var/tmp and var/cache/bind (and i think var/run has to be too). everything else including the config files, and binaries/libraries and the directories they live in should be owned by root and readonly to all others. > This _might_ create a false sense of security. chroot isn't a panacea but it certainly is an improvment. > > If chroot chroot ;) was used (from an external location to the chroot) or > named was called say from '/use/sbin/named -t /var/secure-bind' then of > course this is not an issue. Since the binary that creates the chroot > is not in the chroot itself. the way i do it is the initscript replaces the binaries in the chroot jail before starting them, this way the mainline bind package can get upgraded to fix a security hole and the chroot is upgraded automatically. the binaries in the chroot jail are only writable by root, and of course named does not run as root. (chrooted named running as root is completely pointless). > ii) Is there a particular reason to use /var/secure-bind rather than > say /var/named which seems to be some what of an informal default. > > I'm going to ask on the FHS mailing list about their thoughts on chroot > enviroments and how it might fit in FHS policy. it certainly would be useful to have some standard setup for this kind of thing. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpsfISBgSrRb.pgp
Description: PGP signature