Enable systemd hardening options for named
Ludovic Gasc
gmludo at gmail.com
Tue Jan 16 11:21:38 UTC 2018
Hi,
I have merged config files from Tony, Robert, and me.
I have tried to be the most generic, the result below.
It seems to work here without regression, except a warning:
managed-keys-zone: Unable to fetch DNSKEY set '.': operation canceled
But only at the first boot, I don't see the message anymore when I restart
the daemon.
Any clue ?
Thanks for your feedbacks.
[Unit]
After=network-online.target
[Service]
Type=simple
TimeoutSec=25
Restart=always
RestartSec=1
User=bind
Group=bind
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
SystemCallFilter=~@mount @debug acct modify_ldt add_key adjtimex
clock_adjtime delete_module fanotify_init finit_module get_mempolicy
init_module io_destroy io_getevents iopl ioperm io_setup io_submit
io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages
open_by_handle_at perf_event_open process_vm_readv process_vm_writev ptrace
remap_file_pages request_key set_mempolicy swapoff swapon uselib vmsplice
NoNewPrivileges=true
PrivateDevices=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectControlGroups=true
InaccessiblePaths=/home
InaccessiblePaths=/opt
InaccessiblePaths=/root
ReadWritePaths=/run/named
ReadWritePaths=/var/cache/bind
ReadWritePaths=/var/lib/bind
--
Ludovic Gasc (GMLudo)
2018-01-15 21:14 GMT+01:00 Robert Edmonds <edmonds at mycre.ws>:
> Tony Finch wrote:
> > Ludovic Gasc <gmludo at gmail.com> wrote:
> > >
> > > 1. The list of minimal capabilities needed for bind to run correctly:
> > > http://man7.org/linux/man-pages/man7/capabilities.7.html
> >
> > named already drops capabilities - have a look at the code around here:
> > https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=
> blob;f=bin/named/unix/os.c;hb=v9_11_2#l234
> >
> > Note that it's a bit clever - the privileges are dropped in two stages,
> > right at the start, and after the server has been configured.
>
> I checked just now to see what that code actually ends up doing, and on
> my system I ended up with:
>
> $ grep -h ^Cap /proc/$(pidof named)/**/status | sort | uniq -c
> 6 CapAmb: 0000000000000000
> 6 CapBnd: 0000003fffffffff
> 6 CapEff: 0000000001000400
> 6 CapInh: 0000000000000000
> 6 CapPrm: 0000000001000400
> $
>
> That decodes to:
>
> - The effective and permitted capabilities sets were reduced to
> CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.
>
> - The ambient and inheritable capabilities sets were cleared.
>
> - The capability bounding set was left completely open-ended.
>
> It's not clear why CAP_SYS_RESOURCE needs to be retained past startup:
>
> /*
> * XXX We might want to add CAP_SYS_RESOURCE, though it's not
> * clear it would work right given the way linuxthreads work.
> * XXXDCL But since we need to be able to set the maximum number
> * of files, the stack size, data size, and core dump size to
> * support named.conf options, this is now being added to test.
> */
> SET_CAP(CAP_SYS_RESOURCE);
>
> See commits 5e4b7294d88ab58371d8c98e05ea80086dcb67cd,
> 108490a7f8529aff50a0ac7897580b59a73d9845. "[T]o test"?
>
> CAP_SYS_RESOURCE is documented as permitting:
>
> CAP_SYS_RESOURCE
> * Use reserved space on ext2 filesystems;
> * make ioctl(2) calls controlling ext3 journaling;
> * override disk quota limits;
> * increase resource limits (see setrlimit(2));
> * override RLIMIT_NPROC resource limit;
> * override maximum number of consoles on console allocation;
> * override maximum number of keymaps;
> * allow more than 64hz interrupts from the real-time clock;
> * raise msg_qbytes limit for a System V message queue above the
> limit in /proc/sys/kernel/msgmnb (see msgop(2) and msgctl(2));
> * allow the RLIMIT_NOFILE resource limit on the number of "in-
> flight" file descriptors to be bypassed when passing file
> descriptors to another process via a UNIX domain socket (see
> unix(7));
> * override the /proc/sys/fs/pipe-size-max limit when setting the
> capacity of a pipe using the F_SETPIPE_SZ fcntl(2) command.
> * use F_SETPIPE_SZ to increase the capacity of a pipe above the
> limit specified by /proc/sys/fs/pipe-max-size;
> * override /proc/sys/fs/mqueue/queues_max limit when creating
> POSIX message queues (see mq_overview(7));
> * employ the prctl(2) PR_SET_MM operation;
> * set /proc/[pid]/oom_score_adj to a value lower than the value
> last set by a process with CAP_SYS_RESOURCE.
>
> I would guess that retaining CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE
> during the process runtime permits open-ended reloading of the config at
> runtime (e.g., binding to a new IP address on port 53 without needing to
> restart the daemon). So even though BIND drops some capabilities, it's
> still running with elevated privileges compared to a traditional
> non-root user.
>
> systemd permits a nice pattern for network daemons that want to run as
> an unprivileged user, but bind to a privileged port (and without using
> socket activation), without starting the process as root. Basically, you
> put something like this in the unit file:
>
> [Service]
> User=…
> Group=…
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT CAP_SETPCAP
> AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT CAP_SETPCAP
> …
>
> Any needed filesystem directories and permissions need to be set up
> correctly before hand. The service is started by the init system as the
> unprivileged User/Group specified in the unit file, so there's no need
> to change UID/GID. CAP_NET_BIND_SERVICE is then used to bind to a
> privileged port, CAP_SYS_CHROOT is used to perform the chroot, and
> CAP_SETPCAP is used to drop all remaining capabilities from the
> capability sets and the capability bounding set, so you end up with a
> completely unprivileged process at runtime. (Alternatively you could
> keep CAP_NET_BIND_SERVICE and drop CAP_SYS_CHROOT and CAP_SETPCAP, if
> you wanted to retain the capability to perform privileged binds at
> runtime. Or you could eliminate CAP_SYS_CHROOT and use other systemd
> functionality to make parts of the filesystem inaccessible, etc.) This
> pattern might be a bit hard to retrofit into BIND at this point, though,
> other than by adding more knobs.
>
> --
> Robert Edmonds
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180116/e193b953/attachment.html>
More information about the bind-users
mailing list