We ship them in Fedora, but they're pretty straightforward. We do not
use chroot() as it offers nothing over SElinux, and does not come with
the chroot maintenance nightmare hackery.
IMHO, chroot() for security is pretty much dead. Even without SElinux,
the cost of putting up a VM with only your single daemon makes chroot
basically obsolete. In Fedora you can even use "linux containers", which
uses CGROUPS to run your daemon in isolation.
We ship them in Fedora, but they're pretty straightforward. We do not
use chroot() as it offers nothing over SElinux, and does not come with
the chroot maintenance nightmare hackery.
IMHO, chroot() for security is pretty much dead. Even without SElinux,
the cost of putting up a VM with only your single daemon makes chroot
basically obsolete.
Can't disagree -- if (1) I use Fedora, (2) I use SELinux, and (3) I have
only the single daemon.
In my case, none are true.
I use OpenSuse. I do not use SELinux. I use multiple daemons running
in the VM.
systemd-managed, chroot'd Bind9 is currently one of them, as an example.
In Fedora you can even use "linux containers", which uses CGROUPS to run your daemon in isolation.
My VM is a Xen guest; switching VM tech'y is not an option here. If
you're suggesting running LXC *in* the Xen guest, that's a layered
complexity I'd prefer to do without -- if it's even doable.
In any case, it sounds like users will be on our own to cobble up the
chroot setup up into our systemd init environment, and that it will not
be addressed in the release. True?
I do not speak for the nsd team. I'm simple a user and packager for nsd
on the RHEL and Fedora platform. So I can only tell you that there, we
will never use chroot()