Enable systemd hardening options for named

[Ludovic Gasc]

Hi, More below.

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

> 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.
>

As each year, it was a great event :-)


> > 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.
>

No, I have read that in several setup manual of third party tools that uses
CentOS as basis, but not related with RHEL ressources.
Anyway, it's a reality, and maybe a second level of security might reduce a
little bit the impact.
But, it could also have an impact in term of maintenance and support to
enable these systemd options by default in Fedora, not my role to decide
that ;-)


> > I will ask if there are such statistics.
>

If one moment, you have this information, I'm interested in, if it's
possible to you to communicate on it.


> >     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.
>

The solution might be to add a comment in the named.conf to explain it's
now necessary to change that in systemd unit file.
With the override mechanism of systemd, it's pretty easy to customize a
unit file without to break upgrades.
It's a distribution decision to decide what is the default configuration, I
will check with Debian developers.

Have a nice week.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180207/00d2e9d2/attachment.html>