<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi, More below.</div><div class="gmail_quote"><br></div><div class="gmail_quote">2018-02-06 21:49 GMT+01:00 Petr Menšík <span dir="ltr"><<a href="mailto:pemensik@redhat.com" target="_blank">pemensik@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, More below<br>
<br>
Dne 1.2.2018 v 01:36 Ludovic Gasc napsal(a):<br>
<span class="">> 2018-01-31 21:47 GMT+01:00 Petr Menšík <<a href="mailto:pemensik@redhat.com">pemensik@redhat.com</a><br>
</span>> <mailto:<a href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>>>:<br>
<span class="">><br>
>     Hi Ludovic,<br>
><br>
><br>
> Hi Petr,<br>
><br>
> I didn't expect to discuss directly with the Fedora maintainer :-)<br>
> Just in case you are at DNS devroom of FOSDEM this<br>
> Sunday: <a href="https://fosdem.org/2018/schedule/track/dns/" rel="noreferrer" target="_blank">https://fosdem.org/<wbr>2018/schedule/track/dns/</a><br>
> <<a href="https://fosdem.org/2018/schedule/track/dns/" rel="noreferrer" target="_blank">https://fosdem.org/2018/<wbr>schedule/track/dns/</a>><br>
> I'm interested in to meet you.<br>
<br>
</span>Unfortunately I were not at FOSDEM, so that was not possible. I hope<br>
next time I will be there. I will have to watch the recorded videos.<br></blockquote><div><br></div><div>As each year, it was a great event :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Anyway, about SELinux discussion, I'm convinced that SELinux proposes<br>
> better security features than systemd before it exists.<br>
> However, in Debian universe, no MAC is enabled by default: Some extra<br>
> default config in systemd will be easier to integrate in the mainstream<br>
> distribution than a MAC enabled by default :-)<br>
> Moreover, from my small experience of CentOS, I already seen several<br>
> times in setup documentation of several proprietary software for CentOS<br>
> that the first step is to disable SELinux first before the installation.<br>
</span>There is clear reason why we support our packages and not the third<br>
party ones. This is the best reason for that. I admit maintaining<br>
working SELinux labels is difficult for a person who has minimal<br>
experience with it. I am not quite good myself in fact. However<br>
disabling SELinux at all is the worst practice possible.<br>
<br>
I hope there is nothing like that on any Fedora or Red Hat Enterprise<br>
Linux guides. Switch to permissive mode, use audit2allow, create local<br>
exceptions (semanage), switch back to enforcing. That is what we recommend.<br></blockquote><div><br></div><div>No, I have read that in several setup manual of third party tools that uses CentOS as basis, but not related with RHEL ressources.</div><div>Anyway, it's a reality, and maybe a second level of security might reduce a little bit the impact.<br>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 ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">> </span>I will ask if there are such statistics.<br></blockquote><div><br></div><div>If one moment, you have this information, I'm interested in, if it's possible to you to communicate on it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>     On Fedora, CAP_DAC_OVERRIDE is not granted to bind, because it might be<br>
>     dangerous feature. CAP_DAC_READ_SEARCH is a little bit safer, but still<br>
>     might be unnecessary. It should be possible to run even without it with<br>
>     careful permission configuration of keys and config files.<br>
><br>
>     I think CAP_SYS_RESOURCE is required to automatically adjust maximum<br>
>     number of file descriptors/sockets from configuration. But I am not 100%<br>
>     about that.<br>
><br>
><br>
> For this part, you can define values in systemd config file: LimitNOFILE<br>
</span>Sure, thanks for looking this up. There are 4 limit options in<br>
named.conf for this. files, datasize, coresize, stacksize. I guess all<br>
these values can be configured from systemd instead. In fact, according<br>
to ns_os_adjustnofile of named/main.c, this is always set to<br>
LimitNOFILE=infinity after named starts. At least on my Fedora build of<br>
9.11.2, it is always logged:<br>
"adjusted limit on open files from 2048 to 1048576"<br>
Increasing limit from the service unit will prevent logging this. I<br>
think I want increased limit more obvious.<br>
<br>
Unless you want to disable options from named.conf, CAP_SYS_RESOURCE<br>
should be provided.<br></blockquote><div><br></div><div>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.<br>With the override mechanism of systemd, it's pretty easy to customize a unit file without to break upgrades.</div><div>It's a distribution decision to decide what is the default configuration, I will check with Debian developers.</div><div><br></div><div>Have a nice week.</div></div></div></div>