Re: bind9-chroot (was: questions on ITP)
On Sep 26, Peter Palfrader [EMAIL PROTECTED] wrote: AFAIK mount -o ro --bind /etc/ foo/etc does not mount readonly. So It will in future 2.4 releases. there would be write access to the root partition in the chroot. It does not matter anyway, because the files are owned by root and BIND 9 would not be running as root. -- ciao, Marco
Re: bind9-chroot (was: questions on ITP)
On Tue, Sep 25, 2001 at 11:11:53AM +0200, Martin F Krafft wrote: please explain how a symlink /etc/bind - /var/chroot/bind/etc would be a security problem? That would suck. Config files belong in /etc only. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: bind9-chroot (was: questions on ITP)
* Christian Kurz | On 01-09-25 Steve Greenland wrote: | | I am so tired of hearing things like this. Nobody is forcing anyone to | do anything. We already force them to use 2.2 instead of still using | 2.0. You want the functionality, you use the right tools. You want to | | Were exactly do we force them? Which debian packages do not work well | with a 2.0.x kernel? modutils, iirc. -- Tollef Fog Heen You Can't Win
Re: bind9-chroot (was: questions on ITP)
* Steve Greenland | I am so tired of hearing things like this. Nobody is forcing anyone to | do anything. We already force them to use 2.2 instead of still using | 2.0. You want the functionality, you use the right tools. You want to | stick with 2.2, then *you* deal with the issues. The maintainers have | suggested a reasonable solution. If you don't like that solution, then | it's *your* problem, not theirs. You forget something -- 2.2 is the default kernel on many architectures. The right way is, imho, the way postfix deals with it. It took quite some time before I discovered it chrooted itself. -- Tollef Fog Heen You Can't Win
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Henrique de Moraes Holschuh wrote: On Tue, 25 Sep 2001, Christian Kurz wrote: On 01-09-24 Henrique de Moraes Holschuh wrote: On Mon, 24 Sep 2001, Christian Kurz wrote: Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. In my Oh, how so? I think you know how the method of how to break out of a chroot. Having some symlink inside the chroot would in my opinion make this task easier then it normally is. But feel free to prove me wrong. and would instead suggestion to modify the documents stating that all config files should be in /etc to make a exception for $CHROOT. wears QA hat NEVER. This is not some low-grade distribution where you can go around scattering configuration files all over the filesystem. I will fight tooth and nail against such an atrocity. /wears QA hat Well, then we have to find some other way like cp, rsync, or something else to keep one copy of the files in /etc and one in $CHROOT/etc. Using mount --bind is like I stated before, no option. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp65GidExMe7.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Roberto Suarez Soto wrote: On Sep/25/2001, Christian Kurz wrote: Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? I think that maybe he refers to the fact that, for example, you may have formatted your ext2 partitions so they are incompatible with 2.0.x Well, I once heared about this, but never read an explanation what exactly causes the differences in the ext2 partitions created while running a 2.0.x kernel and why they have been introduced. kernels. Or to the lot of programs (iptables and related, for example) that only work with 2.4.x. Well, iptables is only available for kernel 2.4.x, but with kernel 2.2.x you can still build a firewall with ipchains or ipfwadm if you still use a 2.0.x kernel. So if you want to build a firewall you are not forced to kernel 2.4.x. The decision which kernel and software to use is still left to the administrator. That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Have you tried any *BSD? I would prefer any Debian to them if I had to Yes, I worked quite some time with FreeBSD and also took a short look at NetBSD. (I hadn't time to install OpenBSD for testing purposes.) seriously take charge of one :-) (but again, that's only my opinion; and I'm Well, I wouldn't agree with you, but that's an other discussion which doesn't belong on this list. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpBfNW5Anj13.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Wed, 26 Sep 2001, Christian Kurz wrote: and would instead suggestion to modify the documents stating that all config files should be in /etc to make a exception for $CHROOT. wears QA hat NEVER. This is not some low-grade distribution where you can go around scattering configuration files all over the filesystem. I will fight tooth and nail against such an atrocity. /wears QA hat Well, then we have to find some other way like cp, rsync, or something else to keep one copy of the files in /etc and one in $CHROOT/etc. Using mount --bind is like I stated before, no option. I did not follow the discussion closely, so please forgive me when I'm posting already discussed facts here. The postfix MTA also uses a chroot and in its init.d file and all files needed by the chrooted processes are copied to the chroot upon start of postfix. I do the same with my chrooted bind8. Are there any problems I missed with cimply copying the files? Mount -bind is no option, hardlinks aren't either. Symlinks from inside the chroot to /etc are not possible, the other direction is imho even more evil than cp. yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' :By professionals, | `. `' for professionals http://www.palfrader.org/ | `-http://www.debian.org/
Re: bind9-chroot (was: questions on ITP)
On Sep/26/2001, Christian Kurz wrote: I think that maybe he refers to the fact that, for example, you may have formatted your ext2 partitions so they are incompatible with 2.0.x Well, I once heared about this, but never read an explanation what exactly causes the differences in the ext2 partitions created while running a 2.0.x kernel and why they have been introduced. The features are documented in mke2fs(8), under -O (or it seems, for what I've seen). They don't seem to be too useful (unless I'm missing something), but anyway they are there. Well, iptables is only available for kernel 2.4.x, but with kernel 2.2.x you can still build a firewall with ipchains or ipfwadm if you still use Yes, but it's not the same building a firewall with 2.4.x and building a firewall with 2.2.x or 2.0.x. There are a few things that you can do only with 2.4, not with lower versions. Stateful firewalling, for example. [BSD] seriously take charge of one :-) (but again, that's only my opinion; and I'm Well, I wouldn't agree with you, but that's an other discussion which doesn't belong on this list. Yes. Anyway, I don't think that this was a wrong attitude. As I said, if something is easier upgrading to 2.4.x, I think it's not bad to depend on it. Maybe there should be a easy 2.4.x-dependant bind9-chroot package, and another one, 2.2-2.0 compatible. There are two smbfs packages in a similar state, so why couldn't be two bind9-chroot packages too? -- Roberto Suarez Soto
Re: bind9-chroot (was: questions on ITP)
On Tue, Sep 25, 2001 at 04:34:31PM +0200, Christian Kurz wrote: On 01-09-25 Steve Greenland wrote: I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? apt-cache search usb for example. stick with 2.2, then *you* deal with the issues. The maintainers have That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Forcing new users to deal with historic burden is not an answer. Use a old kernel - loose features. I really can't understand your problem with limiting chroot bind9 feature to kernels with --bind mounts support. They still can run bind9 perfectly, although less securely. If 2.2 kernel users want chrooted bind, they a) have already done it - no extra work b) upgrade to 2.4 - sheez, that was hard... c) do it manually - no more work than it is now who the hell has to do more work, if we add *support* for *automaticly* running bind9 in chroot jail if the kernel supports --bind mounts? -- Riku Voipio|[EMAIL PROTECTED] | kirkkonummentie 33 |+358 40 8476974 --+-- 02140 Espoo| | Facts do not cease to exist because they are ignored. |
Re: bind9-chroot (was: questions on ITP)
On Wed, 26 Sep 2001, Roberto Suarez Soto wrote: On Sep/26/2001, Christian Kurz wrote: I think that maybe he refers to the fact that, for example, you may have formatted your ext2 partitions so they are incompatible with 2.0.x Well, I once heared about this, but never read an explanation what exactly causes the differences in the ext2 partitions created while running a 2.0.x kernel and why they have been introduced. The features are documented in mke2fs(8), under -O (or it seems, for what I've seen). They don't seem to be too useful (unless I'm missing something), but anyway they are there. IIRC ext2 filesystems created with sparse_super mount a lot faster than filesystems created without that option. Ext2 mounts of 20+ Gig filesystems took ages. yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' :By professionals, | `. `' for professionals http://www.palfrader.org/ | `-http://www.debian.org/
Re: bind9-chroot (was: questions on ITP)
Riku Voipio [EMAIL PROTECTED] immo vero scripsit who the hell has to do more work, if we add *support* for *automaticly* running bind9 in chroot jail if the kernel supports --bind mounts? By the way, are we talking about running bind as non-root inside a chroot, or are we talking about running bind as root inside a chroot? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: bind9-chroot (was: questions on ITP)
On 25-Sep-01, 09:34 (CDT), Christian Kurz [EMAIL PROTECTED] wrote: On 01-09-25 Steve Greenland wrote: I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? The standard Debian distribution kernel is 2.2. stick with 2.2, then *you* deal with the issues. The maintainers have That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Why? Because we don't change every aspect of our default system to cater to their individual preferences? One of the reasons that there are so many Linux distributions is that every body has a different idea of the right way, and no single distribution can make everyone happy. That's fine. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: bind9-chroot (was: questions on ITP)
On 01-09-26 Riku Voipio wrote: On Tue, Sep 25, 2001 at 04:34:31PM +0200, Christian Kurz wrote: On 01-09-25 Steve Greenland wrote: I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? apt-cache search usb for example. Which package exactly do you mean? I don't see any package in that list which would force you to use a kernel 2.4.x. Also do you really want to compare hardware for the usb port with a daemon that you run on a server? stick with 2.2, then *you* deal with the issues. The maintainers have That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Forcing new users to deal with historic burden is not an answer. Pardon? New users are absolutely not forced to deal with historic burden. I'm just proposing that any script or debian package which offers to create a bind chroot should not depend on new kernel specific stuff like mount -bind. I really can't understand your problem with limiting chroot bind9 feature to kernels with --bind mounts support. They still can run bind9 perfectly, although less securely. So, you want to either force every admin running bind9 to either upgrade to kernel 2.4.x or have a less secure system? That's like I stated before a good approach if you want to have people move to some other distribution or free operating system, but not to have people use debian anymore. If 2.2 kernel users want chrooted bind, they a) have already done it - no extra work So let's forget those users and ignore that they maybe also happy about having a debian package set up a chroot for them? b) upgrade to 2.4 - sheez, that was hard... Which is not always an option. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpRrzThslsXy.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-26 Roberto Suarez Soto wrote: On Sep/26/2001, Christian Kurz wrote: I think that maybe he refers to the fact that, for example, you may have formatted your ext2 partitions so they are incompatible with 2.0.x Well, I once heared about this, but never read an explanation what exactly causes the differences in the ext2 partitions created while running a 2.0.x kernel and why they have been introduced. The features are documented in mke2fs(8), under -O (or it seems, for what I've seen). They don't seem to be too useful (unless I'm missing something), but anyway they are there. Thanks for the pointer, which explains the features and partly reasons for them. If someone has a pointer to an even more detailed or longer explanation, please mail me. Well, iptables is only available for kernel 2.4.x, but with kernel 2.2.x you can still build a firewall with ipchains or ipfwadm if you still use Yes, but it's not the same building a firewall with 2.4.x and building a firewall with 2.2.x or 2.0.x. There are a few things that you can do only with 2.4, not with lower versions. Stateful firewalling, for example. Well, you may have not the full features available but you can build with all version a firewall and have at least filtering per ip or port available. So compared to the situation with bind, by using cp,rsync or some other tool for keeping the config files in sync, this would still be possible. If mount -bind is used for creating the chroot this would not be possible and it would be like needing kernel 2.4.x for building a firewall. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpf6TNPq43Ox.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Sep 26, Peter Palfrader [EMAIL PROTECTED] wrote: Are there any problems I missed with cimply copying the files? Yes: people do not want to restart bind at every configuration changes. Mount -bind is no option, hardlinks aren't either. Symlinks from mount --bind is the right solution for people using 2.4 kernels. -- ciao, Marco
Re: bind9-chroot (was: questions on ITP)
On Wed, 26 Sep 2001, Marco d'Itri wrote: On Sep 26, Peter Palfrader [EMAIL PROTECTED] wrote: Are there any problems I missed with cimply copying the files? Yes: people do not want to restart bind at every configuration changes. good point. Mount -bind is no option, hardlinks aren't either. Symlinks from mount --bind is the right solution for people using 2.4 kernels. AFAIK mount -o ro --bind /etc/ foo/etc does not mount readonly. So there would be write access to the root partition in the chroot. I usually put chroots in a partition (or lv) of their own. yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' :By professionals, | `. `' for professionals http://www.palfrader.org/ | `-http://www.debian.org/
Re: bind9-chroot (was: questions on ITP)
Peter Palfrader [EMAIL PROTECTED] writes: AFAIK mount -o ro --bind /etc/ foo/etc does not mount readonly. So there would be write access to the root partition in the chroot. If they are not writable by the user of the chroot process, that isn't a problem. If the attacker gets root, the user can break the chroot. -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! Anyone stupid enough to be caught by the police is probably guilty.
Re: bind9-chroot (was: questions on ITP)
also sprach Tollef Fog Heen (on Wed, 26 Sep 2001 10:25:15AM +0200): The right way is, imho, the way postfix deals with it. It took quite some time before I discovered it chrooted itself. i disagree stronlgy mainly because of things like tripwire, which i think should be scanning *everything* but a small list of exceptions - not a list of things to scan and to ignore all rest. /var/spool/postfix contains some very important files that (a) affect the way postfix is working and how secure it is, and (b) are static files in that they don't change between boots. therefore, you tripwire them -- which is useless if every restart of postfix causes tripwire to bitch. martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- pgpQPCcVTxwDs.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
also sprach Junichi Uekawa (on Wed, 26 Sep 2001 09:23:32PM +0900): By the way, are we talking about running bind as non-root inside a chroot, or are we talking about running bind as root inside a chroot? is that a serious question? just *why* would you ever run bind9 as root? martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- pgpE0Ow4QTeTX.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
also sprach Christian Kurz (on Tue, 25 Sep 2001 10:11:07AM +0200): But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. In my opinion there should be absolutely no link from $CHROOT to any file outside the chroot. So instead of creating a $CHROOT that contains everything without any link to the outside you want to decrease the security by having links from outside to inside? I don't agree with that and would instead suggestion to modify the documents stating that all config files should be in /etc to make a exception for $CHROOT. please explain how a symlink /etc/bind - /var/chroot/bind/etc would be a security problem? martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- no problem is so formidable that you can't just walk away from it. -- c. schulz pgpLiQjKjYQwP.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
also sprach Christian Kurz (on Mon, 24 Sep 2001 10:59:13PM +0200): Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. except if you want to enable the usual /etc/bind/ editing of conf-files, which would make administering the chroot no different than administering the non-chrooted bind. martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- time flies like an arrow. fruit flies like a banana. -- groucho marx pgpIhoDxYXrLC.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
also sprach Wichert Akkerman (on Tue, 25 Sep 2001 03:57:49AM +0200): And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. bind mounts. read discussion. martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- you work very hard. don't try to think as well. pgp82fw25ZfNg.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Henrique de Moraes Holschuh wrote: On Mon, 24 Sep 2001, Christian Kurz wrote: Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. In my opinion there should be absolutely no link from $CHROOT to any file outside the chroot. So instead of creating a $CHROOT that contains everything without any link to the outside you want to decrease the security by having links from outside to inside? I don't agree with that and would instead suggestion to modify the documents stating that all config files should be in /etc to make a exception for $CHROOT. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgphj8SPASqTg.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Wichert Akkerman wrote: Previously Henrique de Moraes Holschuh wrote: And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. bind mounts. As I wrote in two emails before, this isn't a solution, since this forces an administrator to use kernel 2.4.x instead of maybe still using 2.2.x. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpjbyKDuFjJj.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Tue, 25 Sep 2001, Christian Kurz wrote: On 01-09-24 Henrique de Moraes Holschuh wrote: On Mon, 24 Sep 2001, Christian Kurz wrote: Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. In my Oh, how so? opinion there should be absolutely no link from $CHROOT to any file outside the chroot. So instead of creating a $CHROOT that contains Get some sleep. Links from inside the chroot to outside do not work, unless the kernel is fucked up. As for Links from outside to inside, please expand on just how they're a threat to security? and would instead suggestion to modify the documents stating that all config files should be in /etc to make a exception for $CHROOT. wears QA hat NEVER. This is not some low-grade distribution where you can go around scattering configuration files all over the filesystem. I will fight tooth and nail against such an atrocity. /wears QA hat -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: bind9-chroot (was: questions on ITP)
On 25-Sep-01, 03:12 (CDT), Christian Kurz [EMAIL PROTECTED] wrote: As I wrote in two emails before, this isn't a solution, since this forces an administrator to use kernel 2.4.x instead of maybe still using 2.2.x. I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to stick with 2.2, then *you* deal with the issues. The maintainers have suggested a reasonable solution. If you don't like that solution, then it's *your* problem, not theirs. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Steve Greenland wrote: On 25-Sep-01, 03:12 (CDT), Christian Kurz [EMAIL PROTECTED] wrote: As I wrote in two emails before, this isn't a solution, since this forces an administrator to use kernel 2.4.x instead of maybe still using 2.2.x. I am so tired of hearing things like this. Nobody is forcing anyone to do anything. We already force them to use 2.2 instead of still using 2.0. You want the functionality, you use the right tools. You want to Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? stick with 2.2, then *you* deal with the issues. The maintainers have That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpAWaw71repF.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Martin F Krafft wrote: also sprach Christian Kurz (on Mon, 24 Sep 2001 10:59:13PM +0200): Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. except if you want to enable the usual /etc/bind/ editing of conf-files, which would make administering the chroot no different than administering the non-chrooted bind. Wouldn't that also be possible by using cp -axp to sync the two copies of the config files? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpZWdtildXMW.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Sep/25/2001, Christian Kurz wrote: Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? I think that maybe he refers to the fact that, for example, you may have formatted your ext2 partitions so they are incompatible with 2.0.x kernels. Or to the lot of programs (iptables and related, for example) that only work with 2.4.x. But anyway, I agree with the poster. I think there are things that are easier to do upgrading to 2.4.x, and trying to do them with 2.2.x may be much worse due to the mess it would be to keep things compatible. My opinion, anyway. That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Have you tried any *BSD? I would prefer any Debian to them if I had to seriously take charge of one :-) (but again, that's only my opinion; and I'm not much knowledgeable in BSD systems anyway) -- Roberto Suarez Soto
Re: bind9-chroot (was: questions on ITP)
On Tue, 25 Sep 2001, Christian Kurz wrote: But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Oh, how so? Because the files accessed from within the chroot once it's broken are the SAME FILES as on the real system. Doesn't that kinda defeat the purpose of having a chroot? Get some sleep. Links from inside the chroot to outside do not work, unless the kernel is fucked up. Hard links work fine. wears QA hat NEVER. This is not some low-grade distribution where you can go around scattering configuration files all over the filesystem. I will fight tooth and nail against such an atrocity. /wears QA hat I agree wholeheartedly here. I don't see what's so hard about rsync'ing the files from /etc to the chroot in the init script each time the daemon is started. -- Sam Couter | Internet Engineer | http://www.topic.com.au/ [EMAIL PROTECTED]| tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C pgpkbczBGVPDX.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
Sam Couter [EMAIL PROTECTED] writes: Because the files accessed from within the chroot once it's broken are the SAME FILES as on the real system. We're not discussing running two binds on a system, one in a chroot and one not. (Although I think I understand your concern now.) We're discussing running exactly one bind in a chroot, so that if bind is exploited, the damage is minimized. Then, for ease of maintenance, we're discussing symlinking /etc/bind to /wherever/chroot/etc/bind, so you can edit the configuration files as if they were in etc. We're on the same page so far, right? Your concern seems to be that an attacker would break the bind within the chroot and edit the configuration files. If the files were copied from a file outside the chroot (and thus out of their realm to modify), you think this would add security, right? It would add as much security to have but one copy of those files modifiable only by root, read-only by anyone else (ie, the bind process in the chroot). Then, unless the attacker managed to get root from bind, they can't modify the files... and if they could get root from bind, they can break the chroot anyway. (man 2 chroot) -- Alan Shutko [EMAIL PROTECTED] - In a variety of flavors! If *I* had a hammer, there'd be no more folk singers.
Re: bind9-chroot (was: questions on ITP)
On Wed, 26 Sep 2001, Sam Couter wrote: On Tue, 25 Sep 2001, Christian Kurz wrote: But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: Oh, how so? Because the files accessed from within the chroot once it's broken are the SAME FILES as on the real system. Doesn't that kinda defeat the purpose of having a chroot? Maybe. But doesn't bind mounts have the same effect (or can one do a read-only bind mount)? One has to choose one of two evils: either use symlinks/bind mounts to have the file being the same, and breaking into the chroot alows one to modify the file. Or copy the file from the canon location into the chroot once in a while [which is what I do]. Get some sleep. Links from inside the chroot to outside do not work, unless the kernel is fucked up. Hard links work fine. Who would do something as stupid as hardlinking to a file inside a chroot? Nevermind, I think I'm happier without this bit of info (I keep chroots in a filesystem of their own for a reason ;) ). wears QA hat NEVER. This is not some low-grade distribution where you can go around scattering configuration files all over the filesystem. I will fight tooth and nail against such an atrocity. /wears QA hat I agree wholeheartedly here. I don't see what's so hard about rsync'ing the files from /etc to the chroot in the init script each time the daemon is started. Which is what I do in my chroot scripts, and what postfix does in its chroot script (and that was exactly the example I gave of chroot done right in sometime ago in this thread). The only thing better than initializing the chroot from a canon copy, would be read-only bind mounts, which are not available in the 2.2 kernels at best. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: bind9-chroot (was: questions on ITP)
On 01-09-23 Martin F Krafft wrote: complicated for i did not know about the mount --bind option. sure, this only works with 2.4.x, but if any chroot changes to bind9 are going public, then this will be bundled with a 2.4.x kernel-image, right? will testing be 2.4.x? So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable solution, since the decision which kernel is used, should never be depending on a chroot-setup, but on the decision of the system administrator. So this script should work with kernel 2.2.x and 2.4.x so that everyone can use it with the kernel version he likes to use. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp1wgch2tmtZ.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
also sprach Christian Kurz (on Mon, 24 Sep 2001 10:31:54AM +0200): So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable solution, since the decision which kernel is used, should never be depending on a chroot-setup, but on the decision of the system administrator. So this script should work with kernel 2.2.x and 2.4.x so that everyone can use it with the kernel version he likes to use. okay, you do have a point. it's not too difficult to make bind chrooted without remounting /etc/bind - one way would be to store $CHROOT/etc/bind in the chroot, and then have a symlink from the real /etc/bind to the chroot one. martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- joan of arc heard voices too. pgp5aBvNzrrQS.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Sep 24, Christian Kurz [EMAIL PROTECTED] wrote: So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable Yes, since managing a chroot environment without bind mounts is way harder and IMO cannot easily/correctly be done by a package. -- ciao, Marco
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Marco d'Itri wrote: On Sep 24, Christian Kurz [EMAIL PROTECTED] wrote: So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable Yes, since managing a chroot environment without bind mounts is way It maybe harder, but that's not a good reason to force system administrator to run a kernel 2.4.x for having the bind debian package chrooted. The reason which kernel version is used on a server should always belong to the admin and should never be imposed by some software. harder and IMO cannot easily/correctly be done by a package. Why not? What do you think makes that part so difficult? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpMGY9yuKZcn.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Martin F Krafft wrote: also sprach Christian Kurz (on Mon, 24 Sep 2001 10:31:54AM +0200): So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable solution, since the decision which kernel is used, should never be depending on a chroot-setup, but on the decision of the system administrator. So this script should work with kernel 2.2.x and 2.4.x so that everyone can use it with the kernel version he likes to use. okay, you do have a point. it's not too difficult to make bind chrooted without remounting /etc/bind - one way would be to store Thanks, that would be in my opinion the best option, since that way every administrator can use the kernel version he wants. $CHROOT/etc/bind in the chroot, and then have a symlink from the real /etc/bind to the chroot one. Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgprw63g9mhDj.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Mon, 24 Sep 2001, Christian Kurz wrote: Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: bind9-chroot (was: questions on ITP)
Previously Henrique de Moraes Holschuh wrote: And scratch the second-most important feature of Debian (the first one being the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it elsewhere, at least leave a symbolic link in place. bind mounts. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: bind9-chroot (was: questions on ITP)
On Sep 22, Bdale Garbee [EMAIL PROTECTED] wrote: Having said that, since I don't personally run bind9 in a chroot, I continue to be willing to accept a clueful patch to the current bind9 source in non-US to implement this... but am in no big rush to implement it myself. There are no packaging changes needed. To chroot bind you just have to fix $OPTS in /etc/init.d/bind9 and create the two mount binds I described earlier. I don't see the point of a bind9-chroot package. -- ciao, Marco
Re: bind9-chroot (was: questions on ITP)
also sprach Marco d'Itri (on Sun, 23 Sep 2001 11:47:33AM +0200):
There are no packaging changes needed.
To chroot bind you just have to fix $OPTS in /etc/init.d/bind9 and
create the two mount binds I described earlier.
marco is right, following his advice, i just chrooted my bind in the
most easiest fashion possible. i have always done it way too
complicated for i did not know about the mount --bind option. sure,
this only works with 2.4.x, but if any chroot changes to bind9 are
going public, then this will be bundled with a 2.4.x kernel-image,
right? will testing be 2.4.x?
i am going to summarize the steps i took to chroot bind9:
CHROOTDIR=/var/lib/bind
# here i have to say that init.d/bind9 lists /var/lib/named, but since
# Debian uses /etc/bind instead of the more common /etc/namedb, i
# suggest going all the way.
# also, init.d/bind9 suggests running as nobody. i find it better to
# have a dedicated user for reasons like protecting reading of
# rndc.conf and others.
# lastly, i suggest making a directory /var/log/bind to place all
# logfiles into, and amending named.conf
this is what debconf should do, if the users wants a chroot:
1) add a user bind with homedir $CHROOTDIR and /bin/false shell,
member of group 'nogroup'
2) mkdir /var/log/bind
chown -R bind.adm /var/log/bind
chmod 2750 /var/log/bind
3) mkdir -p $CHROOTDIR/{var/{log/bind,run},etc/bind}
chown -R bind.nogroup $CHROOTDIR
chmod -R 2700 $CHROOTDIR
4) change $OPTS in init.d/bind9 to
-u bind -t $CHROOTDIR
and this is what init.d/bind9 should do at every start, if chrooted
5) function bind_mount() {
mount | grep -q $2 return 1
mount --bind $1 $2
return $?
}
bind_mount /etc/bind $CHROOTDIR/etc/bind
bind_mount /var/log/bind $CHROOTDIR/var/log/bind
and this is what init.d/bind9 should do at every stop, if chrooted
6) function bind_unmount() {
echo /dev/null
while [ $? = 0 ]; do umount $1 /dev/null; done
}
bind_unmount $CHROOTDIR/etc/bind
bind_unmount $CHROOTDIR/var/log/bind
now, thanks to marco's ingenious hint, you have a chrooted bind, which
won't interfere with tripwire, which does not store anything
changeable on /var/lib, which happily logs
martin; (greetings from the heart of the sun.)
\ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
--
#define emacs eight megabytes and constantly swapping.
pgpY6ll6pkfP7.pgp
Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
WRT chrooting certain applications - wouldn't it make sense to mandate one consistent way for the user to do this if the package supports it? That way, chrooting daemons is much more user-friendly, which in turn will (hopefully) lead to more people doing it. One idea: In a configuration file, the user lists those daemons he wants to run chrooted. init.d scripts that support it read this information and act on it, copying the required files to a chroot before starting the daemon there. (The config file should probably not be read directly, instead the init.d script should call a small query script. That way, file format changes are possible.) Furthermore, IMHO init.d scripts that support chrooting should clearly print [chrooted] or [non-chrooted] in their startup message, both to make the user aware that chrooting is possible, and to make it clear whether it takes place. So: - If I were to put together a chroot-helper package, would people be interested in using it for their package? - Any chance of getting a recommendation for this into policy? Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgpRpbNdfnvwh.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
* Richard Atterer [EMAIL PROTECTED] [010922 16:26]: One idea: In a configuration file, the user lists those daemons he wants to run chrooted. init.d scripts that support it read this information and act on it, copying the required files to a chroot before starting the daemon there. (The config file should probably not be read directly, instead the init.d script should call a small query script. That way, file format changes are possible.) Help, please no. More supports for chroots may be nice. But not this way! init.d-scripts calling scripts, that parse global config files is ugly and one of the many points to make people switch from Suse or Redhat to debian. And why should there be an global config file for all daemons? Beeing chrooted is an quite personal thing for every package. Why should an daemon that run chroot (and there are not that many, that can can be run there) parse a file which is of no interest for him but for the other daemons? Hochachtungsvoll, Bernhard R. Link
Re: bind9-chroot (was: questions on ITP)
also sprach Richard Atterer (on Sat, 22 Sep 2001 03:28:21PM +0200): One idea: In a configuration file, the user lists those daemons he wants to run chrooted. init.d scripts that support it read this information and act on it, copying the required files to a chroot before starting the daemon there. well, you might just use SuSE then... i don't think this is a good idea. for one, it is not necessary to copoy the chroot files over and over again with each init.d start. this interferes with tripwire installations, and it's in violation of the never touch a running system philosophy. even if libc is updated, if bind runs happily in its chroot. and if some security patch or otherwise crucial update is pending for a library that bind also uses, then the bind9 and bind9-chroot packages should be updated anyway. sure, this requires more work on the maintainer side, but it's the best way to do it. - If I were to put together a chroot-helper package, would people be interested in using it for their package? i don't think a global solution is a good choice here. if i install bind9-chroot (hypothetically speaking), then bind9 should not possibly ever run non-chrooted again. this should be done via diversions. martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- you will be run over by a beer truck. pgpNLq6IqYszk.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
[EMAIL PROTECTED] (Martin F Krafft) writes: i don't think a global solution is a good choice here. if i install bind9-chroot (hypothetically speaking), then bind9 should not possibly ever run non-chrooted again. this should be done via diversions. Eee. Diversions are so, well, messy. I think the obvious right way to handle this is to add debconf support to the bind9 package asking whether to run in a chroot or not, and if the answer is yes, just do it. As has been pointed out by Marco and others, bind9 is substantially easier to chroot than previous versions, so this shouldn't be a big deal. Having said that, since I don't personally run bind9 in a chroot, I continue to be willing to accept a clueful patch to the current bind9 source in non-US to implement this... but am in no big rush to implement it myself. Bdale
Re: bind9-chroot (was: questions on ITP)
On Sat, Sep 22, 2001 at 05:39:20PM +0200, Bernhard R. Link wrote: Help, please no. More supports for chroots may be nice. But not this way! init.d-scripts calling scripts, that parse global config files is ugly and one of the many points to make people switch from Suse or Redhat to debian. On Sat, Sep 22, 2001 at 05:46:57PM +0200, Martin F Krafft wrote: well, you might just use SuSE then... :-) The config script was only a suggestion, and maybe there is a better way. But my main point was: Chrooting a daemon should be possible in a uniform way for all daemons that support it. What alternative possibilities for implementing this do you see? The package will have to contain the necessary chrooting script somewhere, and the admin will have to perform some action to trigger its execution. After he has done that, the init.d script should execute the chrooted daemon. It is possible to tell the admin to edit the init.d script, changing some variable assignment to chroot=yes, but somehow I don't think this is very clean, either... Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ ´` ¯ pgp2CxJpGiE30.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
also sprach Bdale Garbee (on Sat, 22 Sep 2001 12:06:37PM -0600): Eee. Diversions are so, well, messy. I think the obvious right way to handle this is to add debconf support to the bind9 package asking whether to run in a chroot or not, and if the answer is yes, just do it. As has been pointed out by Marco and others, bind9 is substantially easier to chroot than previous versions, so this shouldn't be a big deal. well, okay then. i'll paste together a script that will chroot bind right after it was successfully installed as bind9 package, and one which will remove the chroot again. martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- if loving linux is wrong, i don't want to be right. pgpSS5gaKw8IH.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
also sprach Richard Atterer (on Sat, 22 Sep 2001 10:03:55PM +0200): What alternative possibilities for implementing this do you see? The package will have to contain the necessary chrooting script somewhere, and the admin will have to perform some action to trigger its execution. After he has done that, the init.d script should execute the chrooted daemon. i believe that chroot should be an install time choice, not a runtime one (as in config script). martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- la lune, c'est comme les canards il faut aimer caresser les chats pour avoir envie d'y aller. pgpYni67FCDuI.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
Martin F Krafft wrote: also sprach Richard Atterer (on Sat, 22 Sep 2001 10:03:55PM +0200): What alternative possibilities for implementing this do you see? The package will have to contain the necessary chrooting script somewhere, and the admin will have to perform some action to trigger its execution. After he has done that, the init.d script should execute the chrooted daemon. i believe that chroot should be an install time choice, not a runtime one (as in config script). For the long term, this is the safer choice. For even better security, just make the standard install chrooted if it is of wise security reasons to. I've long questioned why this hasn't been done for many daemons already. I know some people may feel that because it breaks something or another one shouldn't do this, but I know bind doesn't break anything by being chrooted. What about others? -- | Bryan Andersen | [EMAIL PROTECTED] | http://www.nerdvest.com | | Buzzwords are like annoying little flies that deserve to be swatted. | | -Bryan Andersen|
Re: bind9-chroot (was: questions on ITP)
On Sat, Sep 22, 2001 at 05:39:20PM +0200, Bernhard R. Link wrote: * Richard Atterer [EMAIL PROTECTED] [010922 16:26]: One idea: In a configuration file, the user lists those daemons he wants to run chrooted. init.d scripts that support it read this information and act on it, copying the required files to a chroot before starting the daemon there. (The config file should probably not be read directly, instead the init.d script should call a small query script. That way, file format changes are possible.) Help, please no. More supports for chroots may be nice. But not this way! init.d-scripts calling scripts, that parse global config files is ugly and one of the many points to make people switch from Suse or Redhat to debian. very much agreed. And why should there be an global config file for all daemons? Beeing chrooted is an quite personal thing for every package. Why should an daemon that run chroot (and there are not that many, that can can be run there) parse a file which is of no interest for him but for the other daemons? yes the proper way is usually /etc/default/package which has config variables for the initscript, such as CHROOT=yes -- Ethan Benson http://www.alaska.net/~erbenson/ pgpMr4lCrK712.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
also sprach Bryan Andersen (on Sat, 22 Sep 2001 05:42:23PM -0500): For even better security, just make the standard install chrooted if it is of wise security reasons to. I've long questioned why this hasn't been done for many daemons already. I know some people may feel that because it breaks something or another one shouldn't do this, but I know bind doesn't break anything by being chrooted. What about others? my postfix runs in a total chroot (even more than standard debian). so does my proftpd. problem with the latter is, of course, that no users can use ftp to access their homedirectories, which i don't consider a problem. i could enable it with 'mount --bind /home /chroot/proftpd/home' but i don't mind imposing sftp on everyone for security reasons anyway! other than that, i have long wanted to set up an apache chroot. i don't know of other daemons (read: i don't use other daemons), which would profit from a chroot... martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- laugh alone and the world thinks you're an idiot. pgpVBMmCiDN7p.pgp Description: PGP signature
bind9-chroot (was: questions on ITP)
also sprach Bdale Garbee (on Thu, 20 Sep 2001 06:00:59PM -0600): bind9-chroot -- convert a bind9 installation to a chroot'd one What does this package do? I have offered numerous times to accept a patch for the bind9 package to optionally implement chroot installation and nobody has taken me up on it. If it's technically reasonable to do so, I'd be willing to look at merging this in to the main bind9 package, possibly using debconf to allow choice of installation model. well, that is certainly an idea. i found myself installing bind9 numerous times and then chrooting it by hand, which can definitely be automated. whether that's done in debconf or by a separate package, well, we'd have to discuss that. i would love to have this package because i am just starting and in search for packages in general, but i see your point. fact is, bind9 does not need to be compiled for chroot like bind8, so it's really easy, even with a binary distribution. how about this: i'll make the package (which will basically be a postinst/prerm pair and nothing else, and then we can always integrate those scripts with the bind9 package. it's nicer to debug and play around when bind9 can just stay on the system. martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] -- ... doch warum sollte nicht jeder einzelne aus seinem leben ein kunstwerk machen koennen? -- michel foucault pgp2TwaZf6J9s.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On Fri, 21 Sep 2001, Martin F Krafft wrote: how about this: i'll make the package (which will basically be a postinst/prerm pair and nothing else, and then we can always integrate IMHO it would be better if you did it the way it is done in the postfix package. The initscript sets up the chroot jail at daemon start (and restart), so that you can easily refresh the libs and conffiles needed inside the jail... (unless bind9 does not need to have any libs and config files such as resolv.conf inside its jail, in which case there is no need for such a script). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: bind9-chroot (was: questions on ITP)
On Sep 21, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: inside the jail... (unless bind9 does not need to have any libs and config files such as resolv.conf inside its jail, in which case there is no need for such a script). It does not. The only things needed are /var/run/, /var/cache/bind/ and a mount --bind remount of /etc/bind . This needs a 2.4 kernel, but there is no administrative overhead. -- ciao, Marco
