Enable systemd hardening options for named

Petr Menšík pemensik at redhat.com
Tue Feb 6 20:49:16 UTC 2018


Hi, More below

Dne 1.2.2018 v 01:36 Ludovic Gasc napsal(a):
> 2018-01-31 21:47 GMT+01:00 Petr Menšík <pemensik at redhat.com
> <mailto: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/
> <https://fosdem.org/2018/schedule/track/dns/>
> I'm interested in to meet you.

Unfortunately I were not at FOSDEM, so that was not possible. I hope
next time I will be there. I will have to watch the recorded videos.

> 
> 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.
There is clear reason why we support our packages and not the third
party ones. This is the best reason for that. I admit maintaining
working SELinux labels is difficult for a person who has minimal
experience with it. I am not quite good myself in fact. However
disabling SELinux at all is the worst practice possible.

I hope there is nothing like that on any Fedora or Red Hat Enterprise
Linux guides. Switch to permissive mode, use audit2allow, create local
exceptions (semanage), switch back to enforcing. That is what we recommend.
> 
> 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.
Interesting question. I have no idea myself, but I would like to get
such answer as well. I will ask if there are such statistics.
>  
> 
> 
>     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
Sure, thanks for looking this up. There are 4 limit options in
named.conf for this. files, datasize, coresize, stacksize. I guess all
these values can be configured from systemd instead. In fact, according
to ns_os_adjustnofile of named/main.c, this is always set to
LimitNOFILE=infinity after named starts. At least on my Fedora build of
9.11.2, it is always logged:
"adjusted limit on open files from 2048 to 1048576"
Increasing limit from the service unit will prevent logging this. I
think I want increased limit more obvious.

Unless you want to disable options from named.conf, CAP_SYS_RESOURCE
should be provided.
>  
> 
>     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.
Sure, sorry for the typo.
>  
> 
> 
>     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
>     <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
>     <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
>     <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
>     <http://man7.org/linux/man-pages/man7/capabilities.7.html>
>     > 2. The list of minimal
>     >
>     SystemCallFilter: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#SystemCallFilter=
>     <https://www.freedesktop.org/software/systemd/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
>     <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe
>     from this list
>     >
>     > bind-users mailing list
>     > bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
>     > https://lists.isc.org/mailman/listinfo/bind-users
>     <https://lists.isc.org/mailman/listinfo/bind-users>
>     >
> 
>     --
>     Petr Menšík
>     Software Engineer
>     Red Hat, http://www.redhat.com/
>     email: pemensik at redhat.com <mailto:pemensik at redhat.com>  PGP: 65C6C973
>     _______________________________________________
>     Please visit https://lists.isc.org/mailman/listinfo/bind-users
>     <https://lists.isc.org/mailman/listinfo/bind-users> to unsubscribe
>     from this list
> 
>     bind-users mailing list
>     bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/bind-users
>     <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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180206/bd53905e/attachment.bin>


More information about the bind-users mailing list