Re: bind-mount of /run/systemd for chrooted bind9/named

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mo, 03.07.23 20:52, Marc Haber (mh+systemd-devel@xxxxxxxxxxxx) wrote:

> (1) go fully systemd
> That would mean to get rid of bind's -t option completely but use
> systemd's RootDirectory directive instead. I have not tried this but I
> think that the bind community might be reluctant to support a setup like
> that. In advantage, I could use the BindReadOnlyPaths directive to
> directly manage the necessary bind mount to make the notify socket
> accessible.

I'd generally advise this, as it means you can drop caps like
CAP_SYS_ADMIN and so on right-away, i.e. all the stuff that chroot()
means.

You don't need to explicitly mount the notify socket if you use this
btw, systemd will do this for you automatically if you combined
RootDirectory= and Type=notify.


> (2) try to preserve the classic setup
> That would probably mean having a
> /etc/systemd/system/var-local-bind-run-systemd.mount with the contents:
> | [Mount]
> | What=/run/systemd
> | Where=/var/local/bind/run/systemd
> | Type=none
> | Options=bind
> |
> | [Install]
> | WantedBy=bind9.service
> and adding a RequiresMountsFor=/var/local/bind/run/systemd to the
> bind9.service.

It should suffice bind mounting just the notify socket, not the full
dir.

You could also use a hybrid approach: let systemd bind mount this for
your service (and thus set up a minimal namespaced env for your
service, but with the root where it normally is), and then still let
bind do its own chroot() thing inside of it).

Generally speaking: its typically a better idea to rely on proper fs
mount namespacing (i.e. decoupling mount tables of services and host)
rather than plain chroot() (where they aren't decoupled). If bind only
does chroot(), then I think using systemd's namespacing is the much
better choice.

> This works as intended when I start up bind9, but when stopping the name
> daemon, the bind mount still lingers around. I have not fully understood
> the necessary systemd magic to have var-local-bind-run-systemd.mount
> stopped whenever bind9.service stops. How would I do that?

You can do Wants= from bind to the mount unit. And then do
StopWhenUnneeded= in the mount unit, to release it when not needed.

So, I personally would always lock things down with systemd mechanisms
(i.e. systemd-analyze security will help you big time). If the daemon
in question then does further lockdown, that's great (as sometimes a
daemon might need privs during startup but not later), but generally
systemd should be better at locking things down, given the seccomp
stuff and all that other stuff it nowadays does.

Lennart

--
Lennart Poettering, Berlin



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux