I would not recommend using own chroot to anyone, who has enabled
SELinux or similar security technology.
We still offer subpackage bind-chroot, which has prepared
named-chroot.service for doing just that. But SELinux provides better
enforcement, while not complicating deployment and usage of named. I
kindly disagree it is still suggested.
Also, BIND9 is full of assertions ensuring unexpected code paths are
reported. This is defensive coding style, which makes it difficult to
success in remote code execution attack. I have been maintainer of BIND
for 6 years, but I am not aware of any successful remote execution in
the last decade. Maybe not ever.
I think the more important protection you can deploy is simple:
Restart=on-abnormal
I think good enough systemd checks are sufficient replacement to custom
tailored chroots.
Cheers,
Petr
On 7/4/23 08:40, Marc Haber wrote:
On Mon, Jul 03, 2023 at 11:21:22PM +0200, Silvio Knizek wrote:
why is it suggested to run `named` within its own chroot? For security reasons? This can be achieved much easier with systemd native options.
That feature is two decades older than systemd, and name server
operators are darn conservative.
Greetings
Marc
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
