net-dns/bind-9.9.3_p2 - chroot jail not implemented for systemd. /usr/lib64/systemd/system/named.service just starts the named daemon: ExecStart=/usr/sbin/named -u named $OPTIONS Reproducible: Always Steps to Reproduce: 1.configure bind to use a chroot jail 2.systemctl start named 3.ps -fu named 4.mount | grep chroot Actual Results: # ps -fu named UID PID PPID C STIME TTY TIME CMD named 5985 1 0 17:18 ? 00:00:00 /usr/sbin/named -u named # findmnt | grep chroot [no output] Expected Results: $ ps -fu named UID PID PPID C STIME TTY TIME CMD named 23618 1 0 dec20 ? 00:01:00 /usr/sbin/named -u named -t /chroot/dns # findmnt | grep chroot [should show the chroot mounts] The chroot feature just doesn't seem to be implemented for systemd. I was thinking to set the severity to major since a security feature has been broken. On the other hand, it just works so it could be minor too. So... I'll leave it in the middle: Normal ;)
I'm sorry but I don't have/use systemd so someone else will have to take a look at it. Perhaps the systemd team might be interested so CC'ing them.
I would call this an enhancement request. We would need to look at a more "systemd-ish" way of implementing this; the openrc init script does a lot of setup work that just is not feasible to do in a systemd service unit.
OpenRC can do this so I'd call this a security issue ;) Anyway, I think the way to go is using a lxc container.
Arch uses a similar approach as us: https://projects.archlinux.org/svntogit/community.git/tree/trunk/named.service?h=packages/bind Fedora does some magic for chroot stuff, relying on an external script: http://pkgs.fedoraproject.org/cgit/bind.git/tree/
(In reply to Mike Gilbert from comment #2) > I would call this an enhancement request. > > We would need to look at a more "systemd-ish" way of implementing this; the > openrc init script does a lot of setup work that just is not feasible to do > in a systemd service unit. I'm just getting into systemd now and it's still a bit overwhelming, but looking at the systemd for admins blog-story series, systemd actually has available besides chroot (which is indeed available) an "even better than chroot" alternative available using kernel namespaces. http://0pointer.de/blog/projects/changing-roots.html Perhaps that could be put in the URL field? Highlights: * Chroots covered using RootDirectory (for the chroot) and ExecStartPre (for the pre-exec directory-setup script). Also available using namespaces (and thus requiring enabling the appropriate kconfig options): * ReadOnlyDirectories, InaccessibleDirectories * PrivateTmp, PrivateNetwork, PrivateDevices (see the systemd.exec manpage, also linked from the above changing-roots blog-story) * systemd-nspawn, a lightweight namespace creation tool. (The description compares it to LXC saying systemd-nspawn is the gnome3 of container solutions, slick and easy but limited options, while LXC is the kde of container solutions, "more configuration options than lines of code.") Given the above features, either a direct chroot implementation or a containers-based implementation should be doable without /too/ much trouble and it /looks/ like it might even be simpler than the openrc solution. If nobody else has gotten there first by the time I get comfortable with systemd I might try creating and posting a preliminary systemd-style solution myself, but it's anyone's guess how soon (or not) I'd get to it. With any luck someone else will get to it first and I'll be spared the trouble. =:^\ Duncan
(In reply to Duncan from comment #5) > (In reply to Mike Gilbert from comment #2) > > We would need to look at a more "systemd-ish" way of implementing this > > If nobody else has gotten there first by the time I get comfortable [...] OK, it's actually quite easy. *IF* you have the mount-binds already setup in your fstab, as I did, so systemd is picking up the mount-binds from there and doing the mounting already, it's as easy as a three-line file dropped in /etc/systemd/system/named.service.d, tho with commments mine's actually a bit longer... You can name the file as you like, as long as it's in the standard local service-file modifications location (/etc/systemd/system/named.service.d), and ends with the *.conf extension. Since it's the execstart line I modified, that's what I called my file here: /etc/systemd/system/named.service.d/execstart.conf : [Service] ExecStart= ExecStart=/usr/sbin/named -f -u named -t /path/to/chroot That's all there is to it. =:^) 1) The [Service] line says it's that section in the service file. 2) The empty ExecStart= line resets that line from the default service file, /usr/share/systemd/system/named.service, so it can be replaced by a new version. 3) The ExecStart=command line is the new version. If you compare it to the ExecStart= line in the original file, all I've done is add the -t and the chroot path. Tho as I mentioned my file is actually a little longer. It has the original ExecStart= line copied as a reference comment (marked with the usual #), and other comments explaining all the commandline options it uses, as well as one additional command-line option (-4, for IPv4 only), while I'm at it. Here's the file as it actually appears here, complete with custom chroot path (/m/cbind): [Service] # original: ExecStart=/usr/sbin/named -f -u named # f=foreground # u=user # 4=IPv4 # t=chroot ExecStart= ExecStart=/usr/sbin/named -f -u named -4 -t /m/cbind For reference, here's what the normal fstab entries with the same chroot path would look like (mine's rather more customized but I'd have to explain it...) And if you set logging to syslog in /etc/bind/named.conf and/or used -g instead of -f in the command above to log it to journald via STDERR, you could get away without the log entry too, making things pretty simple! (If you point a couple more settings away from /run in the config file, you can get away without it too, leaving only /etc/bind and /var/bind as bind-mounts! =:^) /etc/bind /m/cbind/etc/bind none bind 0 0 /run/named /m/cbind/run/named none bind 0 0 /var/bind /m/cbind/var/bind none bind 0 0 /var/log/bind /m/cbind/var/log/bind none bind 0 0 A couple lines in /etc/fstab and a three line config-modifier file in /etc/systemd/system/named.service.d, *MUCH* simpler than the openrc based initscript method! =:^) Duncan
Hm this can be done with bind mounts also, as difficult as systemd does. but it was chosen appearantly to not polute the fstab with a lot of entries that are used for one special case... systemd isn't special in that respect....