Enable systemd hardening options for named

Thu Feb 1 00:36:40 UTC 2018

2018-01-31 21:47 GMT+01:00 Petr Menšík <pemensik at redhat.com>:

> Hi Ludovic,
>

Hi Petr,

I didn't expect to discuss directly with the Fedora maintainer :-)
Just in case you are at DNS devroom of FOSDEM this Sunday:
https://fosdem.org/2018/schedule/track/dns/
I'm interested in to meet you.

Anyway, about SELinux discussion, I'm convinced that SELinux proposes
better security features than systemd before it exists.
However, in Debian universe, no MAC is enabled by default: Some extra
default config in systemd will be easier to integrate in the mainstream
distribution than a MAC enabled by default :-)
Moreover, from my small experience of CentOS, I already seen several times
in setup documentation of several proprietary software for CentOS that the
first step is to disable SELinux first before the installation.

It's up to you to decide what you want to integrate in systemd config file
by default.
For me, it might be complementary: In fact, it might be interesting to know
the pourcentage of CentOS on production without SELinux.

>
> On Fedora, CAP_DAC_OVERRIDE is not granted to bind, because it might be
> dangerous feature. CAP_DAC_READ_SEARCH is a little bit safer, but still
> might be unnecessary. It should be possible to run even without it with
> careful permission configuration of keys and config files.
>
> I think CAP_SYS_RESOURCE is required to automatically adjust maximum
> number of file descriptors/sockets from configuration. But I am not 100%
> about that.
>

For this part, you can define values in systemd config file: LimitNOFILE

> I recently rejected request to change from Type=forking. Has anyone got
> a patch for bind to support Type=notice systemd service? I would like to
> get rid of pid file handling, but Type=simple will not work for me.
>

Type=notify you mean ? Yes, it would be interesting.

>
> I am not sure if PrivateDevices=yes can be used by default on Fedora. We
> package also named-pkcs11 version, which should be able to access
> hardware tokens and accelerators. I doubt it would work with that. I
> want them to still work if they worked until now. Normal variant might
> use that, chroot already has its own empty /dev.
>
> There is some nice page about this on Fedora wiki:
> https://fedoraproject.org/wiki/Packaging:Systemd#Fields_to_avoid
>
>
Thanks for the link, it's interesting.

> Dne 15.1.2018 v 18:58 Ludovic Gasc napsal(a):
> > Hi,
> >
> > (Not sure it's the right mailing-list to discuss about this, tell me if
> > it's another one)
> >
> > For your information, systemd offers several options to increase the
> > security of each daemon based on cgroups, like Docker or rkt.
> > For
> > example: https://www.freedesktop.org/software/systemd/man/
> systemd.exec.html#Capabilities
> >
> > This approach permits to keep the classical Linux distribution daemons
> > with simple maintenance actions via apt or yum + the same container
> > security as a Docker image.
> >
> > A discussion has already started on Debian tracker:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863841
> >
> > Based on this proposal, I made a new service override with extra
> > security (see below).
> >
> > But now, I need your help for two parameters of systemd:
> > 1. The list of minimal capabilities needed for bind to run
> > correctly: http://man7.org/linux/man-pages/man7/capabilities.7.html
> > 2. The list of minimal
> > SystemCallFilter: https://www.freedesktop.org/software/syste
> md/man/systemd.exec.html#SystemCallFilter=
> >
> > Where I could find the lists ?
> >
> > If you have other ideas to increase the security, I'm interested in:
> > My objective is to propose this service file to be integrated in Debian
> > and Fedora.
> >
> > Thanks for your feedback.
> >
> > The service override:
> >
> > [Service]
> > CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_NET_BIND_SERVICE CAP_SETGID
> > CAP_SETUID
> > SystemCallFilter=~@mount @debug
> > 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)
> >
> >
> > _______________________________________________
> > 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
> >
>
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemensik at redhat.com  PGP: 65C6C973
> _______________________________________________
> 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/20180201/fb7498c0/attachment.html>