bind chroot, bind mounts and selinux
Hi All, I'm migrating a CentOS 6 bind instance (chrooted) to a CentOS 7 box and am curious of people's opinions on chrooting vs selinux as a way of securing bind. The bind-chroot on CentOS 7 also comes with a script (/usr/libexec/setup-named-chroot.sh) that sets up the much maligned systemd and, through bind mounts, creates and extra level of chroot hierarchy giving: /var/named/chroot/var/named/chroot/var/named which seems totally unnecessary. I'm sure that bind-chroot would be happy enough running without the bind mounts but would I be loosing anything in terms of security? Also, would I bother with chrooting at all if selinux can secure the environment for me? My own opinions aside what do others think and has anyone had experience with this? Kind regards, Tom -- Tom Robinson 19 Thomas Road Mobile: +61 4 3268 7026 Healesville, VIC 3777 Home: +61 3 5962 4543 Australia GPG Key: 8A4CB7A7 CONFIDENTIALITY: Copyright (C). This message with any appended or attached material is intended for addressees only and may not be copied or forwarded to or used by other parties without permission.
Tom Robinson writes:
The bind-chroot on CentOS 7 also comes with a script (/usr/libexec/setup-named-chroot.sh) that sets up the much maligned systemd and, through bind mounts, creates and extra level of chroot hierarchy giving:
/var/named/chroot/var/named/chroot/var/named which seems totally unnecessary.
Obligatory knee-jerk response: Have you considered nsd3 + unbound instead?
I'm migrating a CentOS 6 bind instance (chrooted) to a CentOS 7 box and am curious of people's opinions on chrooting vs selinux as a way of securing bind.
chroot isn't a security mechanism.
On Thu, 10 Sep 2015 11:52:31 AM Trent W. Buck wrote:
Tom Robinson writes:
The bind-chroot on CentOS 7 also comes with a script (/usr/libexec/setup-named-chroot.sh) that sets up the much maligned systemd and, through bind mounts, creates and extra level of chroot hierarchy giving:
/var/named/chroot/var/named/chroot/var/named which seems totally unnecessary.
Obligatory knee-jerk response: Have you considered nsd3 + unbound instead?
Last time I tried NSD it required a utility from the BIND source tree to copy a zone to a secondary server. It was also annoying to setup. Has it improved in that regard? Apart from being annoying it seemed like a reasonable option. A minimal code base designed to be secure.
I'm migrating a CentOS 6 bind instance (chrooted) to a CentOS 7 box and am curious of people's opinions on chrooting vs selinux as a way of securing bind.
chroot isn't a security mechanism.
BIND drops privs after it starts, so if it's attacked (and if it dropped privs properly) then it won't be able to do any damage that a chroot would stop (IE it can't read home directories etc). If it doesn't drop privs properly (a problem some daemons have had in the past) then it can escape from a chroot. I believe that there is no benefit in allowing a chroot when using SE Linux. If a daemon is to chroot then it needs to be granted the chroot capability and often other access that it wouldn't have if it wasn't chrooted (such as the ability to copy shared objects to the chroot). SE Linux access controls are much more restrictive than a chroot. The access they grant to the filesystem is minimal, a non-chrooted daemon will be able to read lots of files that are part of the OS distribution but that's not a security problem. http://doc.coker.com.au/papers/polyinstantiation-directories-in-se-linux/ If you really want to have restrictions on BIND in addition to SE Linux then the only example I can think of is etc_t which is used for lots of things under /etc. So if you had a different version of /etc for BIND that might give you a benefit. The above URL has a paper I wrote about Polyinstantiated Directories. You could create a special version of /etc for BIND that only has the bare minimum that it needs. But I don't think it's worth the effort. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker <russell@coker.com.au> writes:
On Thu, 10 Sep 2015 11:52:31 AM Trent W. Buck wrote:
Have you considered nsd3 + unbound instead?
Last time I tried NSD it required a utility from the BIND source tree to copy a zone to a secondary server.
I don't know what you mean by that. I transfer zones between my nsd3 and zonedit using AXFR/IXFR. Some zones I'm the primary, some zones zoneedit is the primary.
It was also annoying to setup. Has it improved in that regard?
The "let <IP> ask you about <zone>" needs two lines per IP, where named needs only one. Other than that, for simple usage, I don't know what you mean. PS: also nsd didn't integrate cleanly with upstart, because "reload" &c causes a PID change.
Apart from being annoying it seemed like a reasonable option. A minimal code base designed to be secure.
For me, the advantage is explicit separation between I'm server zone X to the internet! (nsd3) and I'm a caching proxy for my LAN to get zones from the internet! (unbound) With named wearing both hats, I always worry that in any given setup, I haven't fully removed the unwanted hat.
Russell Coker writes:
On Thu, 10 Sep 2015 11:52:31 AM Trent W. Buck wrote:
chroot isn't a security mechanism.
I believe that there is no benefit in allowing a chroot when using SE Linux. If a daemon is to chroot then it needs to be granted the chroot capability [...]
Not strictly true. systemd.exec(5) can chroot before spawning the daemon, the same way it can seteuid before spawning the daemon. Whether this would ACTUALLY be sufficient is... debatable. :-) For named or nsd, I think it would actually make more sense to use the Private*= and *Directories= options to set up a new VFS namespace. IOW rather than named seeing /var/named/chroot as its root, it would see the regular / but with most subdirs hidden. Binding to the low port would be solved either using socket activation (requires patched daemon) or by setpcap CAP_NET_BIND_SERVICE. I'm not sure whether its worth while to do *both* selinux and that kind of security ricing. Probably not.
named and chroot? Was running it for 4 years in a jail. Regards Peter On Fri, Sep 11, 2015 at 10:36 AM, Trent W. Buck <trentbuck@gmail.com> wrote:
Russell Coker writes:
On Thu, 10 Sep 2015 11:52:31 AM Trent W. Buck wrote:
chroot isn't a security mechanism.
I believe that there is no benefit in allowing a chroot when using SE Linux. If a daemon is to chroot then it needs to be granted the chroot capability [...]
Not strictly true.
systemd.exec(5) can chroot before spawning the daemon, the same way it can seteuid before spawning the daemon.
Whether this would ACTUALLY be sufficient is... debatable. :-)
For named or nsd, I think it would actually make more sense to use the Private*= and *Directories= options to set up a new VFS namespace.
IOW rather than named seeing /var/named/chroot as its root, it would see the regular / but with most subdirs hidden.
Binding to the low port would be solved either using socket activation (requires patched daemon) or by setpcap CAP_NET_BIND_SERVICE.
I'm not sure whether its worth while to do *both* selinux and that kind of security ricing. Probably not.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
participants (4)
-
Peter Ross -
Russell Coker -
Tom Robinson -
trentbuck＠gmail.com