Re: Enable systemd hardening options for named

Hi, More below. 2018-02-06 21:49 GMT+01:00 Petr Menšík : > 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 > >: > > > > Hi Ludovic, > > > > > > Hi Petr, > > > > I didn't expect to discuss directly with the

Re: Enable systemd hardening options for named

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

Re: Enable systemd hardening options for named

2018-01-31 21:47 GMT+01:00 Petr Menšík : > 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 discus

Re: Enable systemd hardening options for named

Hi Ludovic, 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 CA

Re: Enable systemd hardening options for named

Dne 31.1.2018 v 15:37 Reindl Harald napsal(a): > > Am 31.01.2018 um 15:18 schrieb Petr Menšík: >> as a Fedora maintainer of BIND package, I can say only that SELinux in >> enforcing mode will provide better hardening than most of suggested >> changes. That does not mean they are not useful, but

Re: Enable systemd hardening options for named

> Am 31.01.2018 um 16:35 schrieb Daniel Stirnimann: >>> that don't change the fact that from that moment on all protections for >>> *that* service are gone while with layered security and >>> systemd-hardening are still in place >> >> Where is the layered security if you disable for e.g. systems-ha

Re: Enable systemd hardening options for named

Am 31.01.2018 um 16:35 schrieb Daniel Stirnimann: that don't change the fact that from that moment on all protections for *that* service are gone while with layered security and systemd-hardening are still in place Where is the layered security if you disable for e.g. systems-hardening for a

Re: Enable systemd hardening options for named

> that don't change the fact that from that moment on all protections for > *that* service are gone while with layered security and > systemd-hardening are still in place Where is the layered security if you disable for e.g. systems-hardening for a service? I don't understand your argument. If y

Re: Enable systemd hardening options for named

Am 31.01.2018 um 16:16 schrieb Daniel Stirnimann: it is completly irrelevant because when you switch SELinux to "permissive" in case you need to debug something it's gone and hence layered-security is always the way to go I don't understand this negative perception of SELinux. Why do you thin

Re: Enable systemd hardening options for named

> it is completly irrelevant because when you switch SELinux to > "permissive" in case you need to debug something it's gone and hence > layered-security is always the way to go I don't understand this negative perception of SELinux. Why do you think debugging differs from any other applied hard

Re: Enable systemd hardening options for named

Am 31.01.2018 um 15:18 schrieb Petr Menšík: as a Fedora maintainer of BIND package, I can say only that SELinux in enforcing mode will provide better hardening than most of suggested changes. That does not mean they are not useful, but most of them are irrelevant with SELinux in enforcing mode.

Re: Enable systemd hardening options for named

Hi, as a Fedora maintainer of BIND package, I can say only that SELinux in enforcing mode will provide better hardening than most of suggested changes. That does not mean they are not useful, but most of them are irrelevant with SELinux in enforcing mode. We want all Fedora users to run in enforci

Re: Enable systemd hardening options for named

Am 16.01.2018 um 13:52 schrieb Daniel Stirnimann: Hello all, Just wondering, if one is already using selinux in enforcing mode, does systemd hardening provide any additional benefit? surely - it's about layered security what are you doing when SELinux makes troubles and you need it so set i

Re: Enable systemd hardening options for named

2018-01-16 13:52 GMT+01:00 Daniel Stirnimann : > Hello all, > > Just wondering, if one is already using selinux in enforcing mode, does > systemd hardening provide any additional benefit? > Very good question, I'm not sure at all: To my understanding, it might be complementary, at least it's poss

Re: Enable systemd hardening options for named

Hello all, Just wondering, if one is already using selinux in enforcing mode, does systemd hardening provide any additional benefit? Daniel On 16.01.18 12:21, Ludovic Gasc wrote: > Hi, > > I have merged config files from Tony, Robert, and me. > I have tried to be the most generic, the result be

Re: Enable systemd hardening options for named

Hi, I have forgotten to say that I have also removed "-u bind" option in /etc/default/bind9, because it isn't necessary anymore: The named daemon is started as bind user directly with this configuration. I might found 3 new interesting options: https://gist.github.com/ageis/f5595e59b1cddb1513d1b4

Re: Enable systemd hardening options for named

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 a

Re: Enable systemd hardening options for named

2018-01-16 11:58 GMT+01:00 Reindl Harald : > > > Am 16.01.2018 um 11:46 schrieb Tony Finch: > >> Robert Edmonds wrote: >> >>> >>> 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.,

Re: Enable systemd hardening options for named

Am 16.01.2018 um 11:46 schrieb Tony Finch: Robert Edmonds wrote: 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 th

Re: Enable systemd hardening options for named

Robert Edmonds wrote: > > 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). BIND since 9.10 listens on

Re: Enable systemd hardening options for named

2018-01-16 10:22 GMT+01:00 Reindl Harald : > > > Am 16.01.2018 um 10:20 schrieb Ludovic Gasc: > >> 2018-01-15 19:11 GMT+01:00 Reindl Harald > h.rei...@thelounge.net>>: >> >> >> ReadOnlyDirectories=/etc >> ReadOnlyDirectories=/usr >> >> >> FYI, you can use ProtectSystem=strict to have more

Re: Enable systemd hardening options for named

Am 16.01.2018 um 10:20 schrieb Ludovic Gasc: 2018-01-15 19:11 GMT+01:00 Reindl Harald >: ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr FYI, you can use ProtectSystem=strict to have more strict rules for the root filesystem: https://www.freedeskto

Re: Enable systemd hardening options for named

2018-01-15 19:11 GMT+01:00 Reindl Harald : > > ReadOnlyDirectories=/etc > ReadOnlyDirectories=/usr > FYI, you can use ProtectSystem=strict to have more strict rules for the root filesystem: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem= _

Re: Enable systemd hardening options for named

First, thank you a lot everybody, I didn't think to have several detailed e-mails like that. I need now to merge all of your ideas and a propose a new version of the config file. However, I answer first to Tony, because I have a remark below: 2018-01-15 19:15 GMT+01:00 Tony Finch : > Ludovic Gas

Re: Enable systemd hardening options for named

Tony Finch wrote: > Ludovic Gasc 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.cg

Re: Enable systemd hardening options for named

Ludovic Gasc 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

Re: Enable systemd hardening options for named

Am 15.01.2018 um 18:58 schrieb Ludovic Gasc: 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:

Enable systemd hardening options for named

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