Re: Enable systemd hardening options for named

[Ludovic Gasc]

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 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.
>
> 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.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

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

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

Re: Enable systemd hardening options for named

[Ludovic Gasc]

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 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@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
>
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemen...@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

Re: Enable systemd hardening options for named

[Petr Menšík]

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 CAP_SYS_RESOURCE is required to automatically adjust maximum
number of file descriptors/sockets from configuration. But I am not 100%
about that.

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.

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

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/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 to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Petr Menšík]

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 most of them are
>> irrelevant with SELinux in enforcing mode. We want all Fedora users to
>> run in enforcing mode, especially on servers.
>>
>> Especially restricting path access does not make sense with SELinux. It
>> is much more powerful and is already used.
> 
> 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
That depends on your needs. Remember we never prevent you from modifying
default configuration to adjust your needs. You can increase security of
your installation any way you wish.

My point is, SELinux is an additional layer to basic security. By basic
security I mean correctly configured permissions on all files.
Up-to-date system with all security updates installed. Correctly
configured ACL.

Usually additional layers provide more security at cost of more checking
and restrictions. They may consume more resources for extra protection.
That resources spend on additional layers are not free. That is why I do
not want to add as much layers as possible - because it is quite
possible they will slow down the server without bringing something real
as a benefit. From what I understood, each PrivateXY= in systemd
requires additional mount. It does not consume much, but still
something. I were able to bring the kernel to knees with one bug related
to mounting. It consumes resources.

CapabilityBoundingSet sounds good, but file access restrictions are
already solved by SELinux. Also with good reporting layer, failures are
visible and more or less understandable. SystemCallFilter sounds
promising. Starting as non-privileged from systemd looks nice too.
> 
> the same for service-configuration even if you have iptables running - i
> had a case some years ago when i tried to enable SELinux on my personal
> machine that i found out failed logins in samba *because* SELinux leaded
> for whatever reason in iptables to fail at boot
I am really sorry for that. If you have trouble with Samba or Iptables,
please fill a bug - http://bugzilla.redhat.com. The point is, that can
happen, you might be forced to set to permissive for a while. Still,
your BIND is not at risk just because of that. Just solve your problem
and turn enforcing back, please. Use semanage to create local exceptions
if required.
> 
>> Dne 16.1.2018 v 13:52 Daniel Stirnimann napsal(a):
>>> 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 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 anymore when I
 restart the daemon.
 Any clue ?

 Thanks for your feedbacks.

 [Unit]
 After=network-online.target

 [Service]
 Type=simple
 TimeoutSec=25
 Restart=always
 RestartSec=1
 User=bind
 Group=bind
 CapabilityBoundingSet=CAP_NET_BIND_SERVICE
 AmbientCapabilities=CAP_NET_BIND_SERVICE
 SystemCallFilter=~@mount @debug acct modify_ldt add_key adjtimex
 clock_adjtime delete_module fanotify_init finit_module get_mempolicy
 init_module io_destroy io_getevents iopl ioperm io_setup io_submit
 io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages
 move_pages
 open_by_handle_at perf_event_open process_vm_readv process_vm_writev
 ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib
 vmsplice

 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)

 2018-01-15 21:14 GMT+01:00 Robert Edmonds >:

  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
  

Re: Enable systemd hardening options for named

[Daniel Stirnimann]

> 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 service? I don't understand your argument. If you don't want to
>> loose the security provided by the hardening, then you should not
>> disable it but fix it
> 
> what exactly do you not understand?

I understood your original answer that you see SELinux as an inferior
approach compared to other hardening mechanisms and I would have liked
to know why.

However, this message made it clear that you favor a layered security
approach which is fine.

Thank you,
Daniel
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Reindl Harald]

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 service? I don't understand your argument. If you don't want to
loose the security provided by the hardening, then you should not
disable it but fix it


what exactly do you not understand?

they guy i repsonded to said with SELinux the hardening options for 
systemd are not required and i explained that they are anyways a good 
idea and why - not more and not less


"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 enforcing mode, especially on servers" was so far OK because it 
statet them as still useful


"Especially restricting path access does not make sense with SELinux. It 
is much more powerful and is already used" is nonsense because when you 
set SELInux global or for the specific service to permissive there is 
nothing powerful left because SELinux was for that case your only 
security layer you just disabled

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Reindl Harald]

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 think
debugging differs from any other applied hardening e.g. linux capabilities?


there was none


From my experience and we had SELinux in enforcing mode on our DNS
servers with BIND for over a year. SELinux provides very clear error
reporting in case anything should go wrong. You can easily modify the
policy or in a worst case, you can set specific services to permissive
mode and leave the rest in enforcing mode


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


it's terrible helpful to have hardening on every stack which provides it 
and be it only because you made a mistake in a SElinux polciy opened 
something which was not by intention


the same for network-layers - just because i have a datacenter firewall 
in place i don't disable iptables/nftables on the machines itself, just 
because i bound the only relevant service to a specfic NIC i don't turn 
off the firewall because when years later someone changes the binding 
without knowing the outcome he exposes the service to the internet while 
with the firewall in place it's still as intended

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[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 think
debugging differs from any other applied hardening e.g. linux capabilities?

>From my experience and we had SELinux in enforcing mode on our DNS
servers with BIND for over a year. SELinux provides very clear error
reporting in case anything should go wrong. You can easily modify the
policy or in a worst case, you can set specific services to permissive
mode and leave the rest in enforcing mode.

Daniel
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Reindl Harald]

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. We want all Fedora users to
run in enforcing mode, especially on servers.

Especially restricting path access does not make sense with SELinux. It
is much more powerful and is already used.


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


the same for service-configuration even if you have iptables running - i 
had a case some years ago when i tried to enable SELinux on my personal 
machine that i found out failed logins in samba *because* SELinux leaded 
for whatever reason in iptables to fail at boot



Dne 16.1.2018 v 13:52 Daniel Stirnimann napsal(a):

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 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 anymore when I
restart the daemon.
Any clue ?

Thanks for your feedbacks.

[Unit]
After=network-online.target

[Service]
Type=simple
TimeoutSec=25
Restart=always
RestartSec=1
User=bind
Group=bind
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
SystemCallFilter=~@mount @debug acct modify_ldt add_key adjtimex
clock_adjtime delete_module fanotify_init finit_module get_mempolicy
init_module io_destroy io_getevents iopl ioperm io_setup io_submit
io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages
open_by_handle_at perf_event_open process_vm_readv process_vm_writev
ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib
vmsplice

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)

2018-01-15 21:14 GMT+01:00 Robert Edmonds >:

 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.cgi?p=bind9.git;a=blob;f=bin/named/unix/os.c;hb=v9_11_2#l234
 

 >
 > Note that it's a bit clever - the privileges are dropped in two stages,
 > right at the start, and after the server has been configured.

 I checked just now to see what that code actually ends up doing, and on
 my system I ended up with:

     $ grep -h ^Cap /proc/$(pidof named)/**/status | sort | uniq -c
           6 CapAmb:     
           6 CapBnd:     003f
           6 CapEff:     01000400
           6 CapInh:     
           6 CapPrm:     01000400
     $

 That decodes to:

  - The effective and permitted capabilities sets were reduced to
    CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.

  - The ambient and inheritable capabilities sets were cleared.

  - The capability bounding set was left completely open-ended.

 It's not clear why CAP_SYS_RESOURCE needs to be retained past startup:

         /*
          * XXX  We might want to add CAP_SYS_RESOURCE, though it's not
          *      clear it would work right given the way linuxthreads
 work.
          * XXXDCL But since we need to be able to set the maximum number
          * of files, the stack size, data size, and core dump size to
          * support named.conf options, this is now being added to test.
          */
         SET_CAP(CAP_SYS_RESOURCE);

 See commits 5e4b7294d88ab58371d8c98e05ea80086dcb67cd,
 108490a7f8529aff50a0ac7897580b59a73d9845. "[T]o test"?

 CAP_SYS_RESOURCE is documented as permitting:

    CAP_SYS_RESOURCE
           * Use reserved space on ext2 filesystems;
           * make ioctl(2) calls controlling ext3 journaling;
           * override disk 

Re: Enable systemd hardening options for named

[Petr Menšík]

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 enforcing mode, especially on servers.

Especially restricting path access does not make sense with SELinux. It
is much more powerful and is already used.

Dne 16.1.2018 v 13:52 Daniel Stirnimann napsal(a):
> 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 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 anymore when I
>> restart the daemon.
>> Any clue ?
>>
>> Thanks for your feedbacks.
>>
>> [Unit]
>> After=network-online.target
>>
>> [Service]
>> Type=simple
>> TimeoutSec=25
>> Restart=always
>> RestartSec=1
>> User=bind
>> Group=bind
>> CapabilityBoundingSet=CAP_NET_BIND_SERVICE
>> AmbientCapabilities=CAP_NET_BIND_SERVICE
>> SystemCallFilter=~@mount @debug acct modify_ldt add_key adjtimex
>> clock_adjtime delete_module fanotify_init finit_module get_mempolicy
>> init_module io_destroy io_getevents iopl ioperm io_setup io_submit
>> io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages
>> open_by_handle_at perf_event_open process_vm_readv process_vm_writev
>> ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib
>> vmsplice
>>
>> 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)
>>
>> 2018-01-15 21:14 GMT+01:00 Robert Edmonds > >:
>>
>> 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.cgi?p=bind9.git;a=blob;f=bin/named/unix/os.c;hb=v9_11_2#l234
>> 
>> 
>> >
>> > Note that it's a bit clever - the privileges are dropped in two stages,
>> > right at the start, and after the server has been configured.
>>
>> I checked just now to see what that code actually ends up doing, and on
>> my system I ended up with:
>>
>>     $ grep -h ^Cap /proc/$(pidof named)/**/status | sort | uniq -c
>>           6 CapAmb:     
>>           6 CapBnd:     003f
>>           6 CapEff:     01000400
>>           6 CapInh:     
>>           6 CapPrm:     01000400
>>     $
>>
>> That decodes to:
>>
>>  - The effective and permitted capabilities sets were reduced to
>>    CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.
>>
>>  - The ambient and inheritable capabilities sets were cleared.
>>
>>  - The capability bounding set was left completely open-ended.
>>
>> It's not clear why CAP_SYS_RESOURCE needs to be retained past startup:
>>
>>         /*
>>          * XXX  We might want to add CAP_SYS_RESOURCE, though it's not
>>          *      clear it would work right given the way linuxthreads
>> work.
>>          * XXXDCL But since we need to be able to set the maximum number
>>          * of files, the stack size, data size, and core dump size to
>>          * support named.conf options, this is now being added to test.
>>          */
>>         SET_CAP(CAP_SYS_RESOURCE);
>>
>> See commits 5e4b7294d88ab58371d8c98e05ea80086dcb67cd,
>> 108490a7f8529aff50a0ac7897580b59a73d9845. "[T]o test"?
>>
>> CAP_SYS_RESOURCE is documented as permitting:
>>
>>    CAP_SYS_RESOURCE
>>           * Use reserved space on ext2 filesystems;
>>           * make ioctl(2) calls controlling ext3 journaling;
>>           * override disk quota limits;
>>           * increase resource limits (see setrlimit(2));
>>           * override RLIMIT_NPROC resource limit;
>>           * override maximum number of consoles on console 

Re: Enable systemd hardening options for named

[Reindl Harald]

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 it 
"permissive" to get anything running at all? if you rely on SELinux 
alsone all your shields are down

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Ludovic Gasc]

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 possible in
systemd config to apply a SELinux context:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Mandatory%20Access%20Control

It's clearly possible that all options we have put in the systemd config
file has an equivalent in SELinux/AppArmor/SMACK and that its propose more
security options than systemd. But I have only basic knowledge on these
technologies, interested in by feedbacks from a person who has written
rules with that.

The main advantage I see to work on this systemd config file is to increase
the default security configuration in major distributions without extra
dependencies: 99% of people don't customize the default daemons config
setup, and SELinux/AppArmor/SMACK aren't always used.


>
> 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 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 anymore when I
> > restart the daemon.
> > Any clue ?
> >
> > Thanks for your feedbacks.
> >
> > [Unit]
> > After=network-online.target
> >
> > [Service]
> > Type=simple
> > TimeoutSec=25
> > Restart=always
> > RestartSec=1
> > User=bind
> > Group=bind
> > CapabilityBoundingSet=CAP_NET_BIND_SERVICE
> > AmbientCapabilities=CAP_NET_BIND_SERVICE
> > SystemCallFilter=~@mount @debug acct modify_ldt add_key adjtimex
> > clock_adjtime delete_module fanotify_init finit_module get_mempolicy
> > init_module io_destroy io_getevents iopl ioperm io_setup io_submit
> > io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages
> > open_by_handle_at perf_event_open process_vm_readv process_vm_writev
> > ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib
> > vmsplice
> >
> > 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)
> >
> > 2018-01-15 21:14 GMT+01:00 Robert Edmonds  > >:
> >
> > 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.cgi?p=bind9.git;a=
> blob;f=bin/named/unix/os.c;hb=v9_11_2#l234
> >  blob;f=bin/named/unix/os.c;hb=v9_11_2#l234>
> > >
> > > Note that it's a bit clever - the privileges are dropped in two
> stages,
> > > right at the start, and after the server has been configured.
> >
> > I checked just now to see what that code actually ends up doing, and
> on
> > my system I ended up with:
> >
> > $ grep -h ^Cap /proc/$(pidof named)/**/status | sort | uniq -c
> >   6 CapAmb: 
> >   6 CapBnd: 003f
> >   6 CapEff: 01000400
> >   6 CapInh: 
> >   6 CapPrm: 01000400
> > $
> >
> > That decodes to:
> >
> >  - The effective and permitted capabilities sets were reduced to
> >CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.
> >
> >  - The ambient and inheritable capabilities sets were cleared.
> >
> >  - The capability bounding set was left completely open-ended.
> >
> > It's not clear why CAP_SYS_RESOURCE needs to be retained past
> startup:
> >
> > /*
> >  * XXX  We might want to add CAP_SYS_RESOURCE, though it's
> not
> >  *  clear it would work right given the way linuxthreads
> > work.
> >  * XXXDCL But since we need to be able to set the maximum
> number
> >  * of files, the stack size, data size, and core dump size to
> >  * support named.conf options, this is now being added to
> test.
> >  */
> > SET_CAP(CAP_SYS_RESOURCE);
> >
> > See commits 

Re: Enable systemd hardening options for named

[Daniel Stirnimann]

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 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 anymore when I
> restart the daemon.
> Any clue ?
> 
> Thanks for your feedbacks.
> 
> [Unit]
> After=network-online.target
> 
> [Service]
> Type=simple
> TimeoutSec=25
> Restart=always
> RestartSec=1
> User=bind
> Group=bind
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE
> AmbientCapabilities=CAP_NET_BIND_SERVICE
> SystemCallFilter=~@mount @debug acct modify_ldt add_key adjtimex
> clock_adjtime delete_module fanotify_init finit_module get_mempolicy
> init_module io_destroy io_getevents iopl ioperm io_setup io_submit
> io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages
> open_by_handle_at perf_event_open process_vm_readv process_vm_writev
> ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib
> vmsplice
> 
> 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)
> 
> 2018-01-15 21:14 GMT+01:00 Robert Edmonds  >:
> 
> 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.cgi?p=bind9.git;a=blob;f=bin/named/unix/os.c;hb=v9_11_2#l234
> 
> 
> >
> > Note that it's a bit clever - the privileges are dropped in two stages,
> > right at the start, and after the server has been configured.
> 
> I checked just now to see what that code actually ends up doing, and on
> my system I ended up with:
> 
>     $ grep -h ^Cap /proc/$(pidof named)/**/status | sort | uniq -c
>           6 CapAmb:     
>           6 CapBnd:     003f
>           6 CapEff:     01000400
>           6 CapInh:     
>           6 CapPrm:     01000400
>     $
> 
> That decodes to:
> 
>  - The effective and permitted capabilities sets were reduced to
>    CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.
> 
>  - The ambient and inheritable capabilities sets were cleared.
> 
>  - The capability bounding set was left completely open-ended.
> 
> It's not clear why CAP_SYS_RESOURCE needs to be retained past startup:
> 
>         /*
>          * XXX  We might want to add CAP_SYS_RESOURCE, though it's not
>          *      clear it would work right given the way linuxthreads
> work.
>          * XXXDCL But since we need to be able to set the maximum number
>          * of files, the stack size, data size, and core dump size to
>          * support named.conf options, this is now being added to test.
>          */
>         SET_CAP(CAP_SYS_RESOURCE);
> 
> See commits 5e4b7294d88ab58371d8c98e05ea80086dcb67cd,
> 108490a7f8529aff50a0ac7897580b59a73d9845. "[T]o test"?
> 
> CAP_SYS_RESOURCE is documented as permitting:
> 
>    CAP_SYS_RESOURCE
>           * Use reserved space on ext2 filesystems;
>           * make ioctl(2) calls controlling ext3 journaling;
>           * override disk quota limits;
>           * increase resource limits (see setrlimit(2));
>           * override RLIMIT_NPROC resource limit;
>           * override maximum number of consoles on console allocation;
>           * override maximum number of keymaps;
>           * allow more than 64hz interrupts from the real-time clock;
>           * raise msg_qbytes limit for a System V message queue
> above  the
>             limit in /proc/sys/kernel/msgmnb (see msgop(2) and
> msgctl(2));
>           * allow  the  RLIMIT_NOFILE resource limit on the number
> of "in-
>             flight" file descriptors to  be  bypassed  when 
> passing  file
>             descriptors  to  another process via a UNIX domain
> socket (see
>             unix(7));
>       

Re: Enable systemd hardening options for named

[Ludovic Gasc]

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/f5595e59b1cddb1513d1b425a323db04
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
RestrictRealtime=true


--
Ludovic Gasc (GMLudo)

2018-01-16 12:21 GMT+01:00 Ludovic Gasc :

> 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 anymore when I restart
> the daemon.
> Any clue ?
>
> Thanks for your feedbacks.
>
> [Unit]
> After=network-online.target
>
> [Service]
> Type=simple
> TimeoutSec=25
> Restart=always
> RestartSec=1
> User=bind
> Group=bind
> CapabilityBoundingSet=CAP_NET_BIND_SERVICE
> AmbientCapabilities=CAP_NET_BIND_SERVICE
> SystemCallFilter=~@mount @debug acct modify_ldt add_key adjtimex
> clock_adjtime delete_module fanotify_init finit_module get_mempolicy
> init_module io_destroy io_getevents iopl ioperm io_setup io_submit
> io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages
> open_by_handle_at perf_event_open process_vm_readv process_vm_writev ptrace
> remap_file_pages request_key set_mempolicy swapoff swapon uselib vmsplice
>
> 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)
>
> 2018-01-15 21:14 GMT+01:00 Robert Edmonds :
>
>> 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.cgi?p=bind9.git;a=blob
>> ;f=bin/named/unix/os.c;hb=v9_11_2#l234
>> >
>> > Note that it's a bit clever - the privileges are dropped in two stages,
>> > right at the start, and after the server has been configured.
>>
>> I checked just now to see what that code actually ends up doing, and on
>> my system I ended up with:
>>
>> $ grep -h ^Cap /proc/$(pidof named)/**/status | sort | uniq -c
>>   6 CapAmb: 
>>   6 CapBnd: 003f
>>   6 CapEff: 01000400
>>   6 CapInh: 
>>   6 CapPrm: 01000400
>> $
>>
>> That decodes to:
>>
>>  - The effective and permitted capabilities sets were reduced to
>>CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.
>>
>>  - The ambient and inheritable capabilities sets were cleared.
>>
>>  - The capability bounding set was left completely open-ended.
>>
>> It's not clear why CAP_SYS_RESOURCE needs to be retained past startup:
>>
>> /*
>>  * XXX  We might want to add CAP_SYS_RESOURCE, though it's not
>>  *  clear it would work right given the way linuxthreads work.
>>  * XXXDCL But since we need to be able to set the maximum number
>>  * of files, the stack size, data size, and core dump size to
>>  * support named.conf options, this is now being added to test.
>>  */
>> SET_CAP(CAP_SYS_RESOURCE);
>>
>> See commits 5e4b7294d88ab58371d8c98e05ea80086dcb67cd,
>> 108490a7f8529aff50a0ac7897580b59a73d9845. "[T]o test"?
>>
>> CAP_SYS_RESOURCE is documented as permitting:
>>
>>CAP_SYS_RESOURCE
>>   * Use reserved space on ext2 filesystems;
>>   * make ioctl(2) calls controlling ext3 journaling;
>>   * override disk quota limits;
>>   * increase resource limits (see setrlimit(2));
>>   * override RLIMIT_NPROC resource limit;
>>   * override maximum number of consoles on console allocation;
>>   * override maximum number of keymaps;
>>   * allow more than 64hz interrupts from the real-time clock;
>>   * raise msg_qbytes limit for a System V message queue above  the
>> limit in /proc/sys/kernel/msgmnb (see msgop(2) and msgctl(2));
>>   * allow  the  RLIMIT_NOFILE resource limit on the number of "in-
>> flight" file descriptors to  be  bypassed  when  passing  file
>> descriptors  to  another process via a UNIX domain socket (see
>> unix(7));
>>   * override the /proc/sys/fs/pipe-size-max limit when setting the
>> capacity of a pipe using the F_SETPIPE_SZ fcntl(2) 

Re: Enable systemd hardening options for named

[Ludovic Gasc]

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 anymore when I restart
the daemon.
Any clue ?

Thanks for your feedbacks.

[Unit]
After=network-online.target

[Service]
Type=simple
TimeoutSec=25
Restart=always
RestartSec=1
User=bind
Group=bind
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
SystemCallFilter=~@mount @debug acct modify_ldt add_key adjtimex
clock_adjtime delete_module fanotify_init finit_module get_mempolicy
init_module io_destroy io_getevents iopl ioperm io_setup io_submit
io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages
open_by_handle_at perf_event_open process_vm_readv process_vm_writev ptrace
remap_file_pages request_key set_mempolicy swapoff swapon uselib vmsplice

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)

2018-01-15 21:14 GMT+01:00 Robert Edmonds :

> 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.cgi?p=bind9.git;a=
> blob;f=bin/named/unix/os.c;hb=v9_11_2#l234
> >
> > Note that it's a bit clever - the privileges are dropped in two stages,
> > right at the start, and after the server has been configured.
>
> I checked just now to see what that code actually ends up doing, and on
> my system I ended up with:
>
> $ grep -h ^Cap /proc/$(pidof named)/**/status | sort | uniq -c
>   6 CapAmb: 
>   6 CapBnd: 003f
>   6 CapEff: 01000400
>   6 CapInh: 
>   6 CapPrm: 01000400
> $
>
> That decodes to:
>
>  - The effective and permitted capabilities sets were reduced to
>CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.
>
>  - The ambient and inheritable capabilities sets were cleared.
>
>  - The capability bounding set was left completely open-ended.
>
> It's not clear why CAP_SYS_RESOURCE needs to be retained past startup:
>
> /*
>  * XXX  We might want to add CAP_SYS_RESOURCE, though it's not
>  *  clear it would work right given the way linuxthreads work.
>  * XXXDCL But since we need to be able to set the maximum number
>  * of files, the stack size, data size, and core dump size to
>  * support named.conf options, this is now being added to test.
>  */
> SET_CAP(CAP_SYS_RESOURCE);
>
> See commits 5e4b7294d88ab58371d8c98e05ea80086dcb67cd,
> 108490a7f8529aff50a0ac7897580b59a73d9845. "[T]o test"?
>
> CAP_SYS_RESOURCE is documented as permitting:
>
>CAP_SYS_RESOURCE
>   * Use reserved space on ext2 filesystems;
>   * make ioctl(2) calls controlling ext3 journaling;
>   * override disk quota limits;
>   * increase resource limits (see setrlimit(2));
>   * override RLIMIT_NPROC resource limit;
>   * override maximum number of consoles on console allocation;
>   * override maximum number of keymaps;
>   * allow more than 64hz interrupts from the real-time clock;
>   * raise msg_qbytes limit for a System V message queue above  the
> limit in /proc/sys/kernel/msgmnb (see msgop(2) and msgctl(2));
>   * allow  the  RLIMIT_NOFILE resource limit on the number of "in-
> flight" file descriptors to  be  bypassed  when  passing  file
> descriptors  to  another process via a UNIX domain socket (see
> unix(7));
>   * override the /proc/sys/fs/pipe-size-max limit when setting the
> capacity of a pipe using the F_SETPIPE_SZ fcntl(2) command.
>   * use  F_SETPIPE_SZ to increase the capacity of a pipe above the
> limit specified by /proc/sys/fs/pipe-max-size;
>   * override /proc/sys/fs/mqueue/queues_max  limit  when  creating
> POSIX message queues (see mq_overview(7));
>   * employ the prctl(2) PR_SET_MM operation;
>   * set  /proc/[pid]/oom_score_adj to a value lower than the value
> last set by a process with CAP_SYS_RESOURCE.
>
> 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

[Ludovic Gasc]

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., binding to a new IP address on port 53 without needing to
>>> restart the daemon).
>>>
>>
>> BIND since 9.10 listens on the routing socket so it can spot network
>> interfaces coming and going automatically, without needing an explicit
>> `rndc reconfig` or `rndc scan`. This works very nicely with `keepalived` -
>> I use it for failover in my production resolver cluster.
>>
>
Good to know, thanks for the information.


> (I avoid systemd: journald makes it so difficult to get logs out that I
>> get angry every time I encounter it, and systemd has a habit of believing
>> that a service is working when it isn't. I've had enough pain in test
>> environments that I don't want to use it in production.)
>>
>
> well, complete infrastructure running from 2011 until now with systemd


The goal of my e-mail wasn't to have a debate about the interest of systemd
:-)

Personally, we use systemd+journald on production since 2015. Even if the
beginning was complicated, the time we needed to learn and especially about
performances issues in journald, since we use systemd backports on Debian,
it's OK now. And we have upgraded to Debian stretch, nothing special to do
anymore.

However, it's technically possible to replace most systemd features by
several other technologies, and certainly with more options.
Nevertheless, from my past experience with other solutions, systemd is good
enough for most use cases.

While nobody forbids me to use systemd features, it's OK for me that other
people use other technologies ;-)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[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., binding to a new IP address on port 53 without needing to
restart the daemon).


BIND since 9.10 listens on the routing socket so it can spot network
interfaces coming and going automatically, without needing an explicit
`rndc reconfig` or `rndc scan`. This works very nicely with `keepalived` -
I use it for failover in my production resolver cluster.

(I avoid systemd: journald makes it so difficult to get logs out that I
get angry every time I encounter it, and systemd has a habit of believing
that a service is working when it isn't. I've had enough pain in test
environments that I don't want to use it in production.)


well, complete infrastructure running from 2011 until now with systemd

especially the journald problem is nonsense - just configure rsyslog as 
all the years before but with less hidden messages because you have 
eraly boot from second one and stdout/stderr of services also relieable 
collected


[root@srv-rhsoft:~]$ cat /etc/systemd/journald.conf
[Journal]
Storage=volatile

[root@srv-rhsoft:~]$ cat rsyslog.conf
 MODULES 
$ModLoad imjournal
$MainMsgQueueSize 10
$WorkDirectory /var/lib/rsyslog
$IMJournalStateFile imjournal.state
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[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 the daemon).

BIND since 9.10 listens on the routing socket so it can spot network
interfaces coming and going automatically, without needing an explicit
`rndc reconfig` or `rndc scan`. This works very nicely with `keepalived` -
I use it for failover in my production resolver cluster.

(I avoid systemd: journald makes it so difficult to get logs out that I
get angry every time I encounter it, and systemd has a habit of believing
that a service is working when it isn't. I've had enough pain in test
environments that I don't want to use it in production.)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Portland: West 7 to severe gale 9. Rough or very rough, becoming high in
southwest. Squally showers. Good, occasionally moderate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Ludovic Gasc]

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 strict rules for the
>> root filesystem:
>> https://www.freedesktop.org/software/systemd/man/systemd.exe
>> c.html#ProtectSystem=
>>
>
> in reality i go even mor far and start with ReadOnlyDirectories=/ followed
> by selective multiple "ReadWriteDirectories=" and a ton of
> "InaccessibleDirectories=" but that's out of scope here because it depends
> too much on the local environment :-)


Ok ;-)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Reindl Harald]

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.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=


in reality i go even mor far and start with ReadOnlyDirectories=/ 
followed by selective multiple "ReadWriteDirectories=" and a ton of 
"InaccessibleDirectories=" but that's out of scope here because it 
depends too much on the local environment :-)

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[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.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectSystem=
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Ludovic Gasc]

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 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/unix/os.c;hb=v9_11_2#l234
>
> Note that it's a bit clever - the privileges are dropped in two stages,
> right at the start, and after the server has been configured.
>

One of motivation behind systemd is to have all daemonization features
(start in root and drop rights to run with a normal user, chroot,
background processes...) outside the daemon itself to reduce the security
risk, share the same code for daemonization and reduce the complexity of
each daemon.
In the specific case of bind, it already has these features and bind runs
on OS where you don't have systemd.

As you said, I don't think it hurts if it's done two times, I don't yet, I
will experiment.


>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
> punycode
> Southeast Iceland: Westerly 6 to gale 8, veering northwesterly 4 or 5
> later,
> occasionally severe gale 9 at first in south. Very rough in north,
> otherwise
> high, occasionally very high in far south. Snow showers. Good occasionally
> poor.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Robert Edmonds]

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.cgi?p=bind9.git;a=blob;f=bin/named/unix/os.c;hb=v9_11_2#l234
> 
> Note that it's a bit clever - the privileges are dropped in two stages,
> right at the start, and after the server has been configured.

I checked just now to see what that code actually ends up doing, and on
my system I ended up with:

$ grep -h ^Cap /proc/$(pidof named)/**/status | sort | uniq -c
  6 CapAmb: 
  6 CapBnd: 003f
  6 CapEff: 01000400
  6 CapInh: 
  6 CapPrm: 01000400
$

That decodes to:

 - The effective and permitted capabilities sets were reduced to
   CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE.

 - The ambient and inheritable capabilities sets were cleared.

 - The capability bounding set was left completely open-ended.

It's not clear why CAP_SYS_RESOURCE needs to be retained past startup:

/*
 * XXX  We might want to add CAP_SYS_RESOURCE, though it's not
 *  clear it would work right given the way linuxthreads work.
 * XXXDCL But since we need to be able to set the maximum number
 * of files, the stack size, data size, and core dump size to
 * support named.conf options, this is now being added to test.
 */
SET_CAP(CAP_SYS_RESOURCE);

See commits 5e4b7294d88ab58371d8c98e05ea80086dcb67cd,
108490a7f8529aff50a0ac7897580b59a73d9845. "[T]o test"?

CAP_SYS_RESOURCE is documented as permitting:

   CAP_SYS_RESOURCE
  * Use reserved space on ext2 filesystems;
  * make ioctl(2) calls controlling ext3 journaling;
  * override disk quota limits;
  * increase resource limits (see setrlimit(2));
  * override RLIMIT_NPROC resource limit;
  * override maximum number of consoles on console allocation;
  * override maximum number of keymaps;
  * allow more than 64hz interrupts from the real-time clock;
  * raise msg_qbytes limit for a System V message queue above  the
limit in /proc/sys/kernel/msgmnb (see msgop(2) and msgctl(2));
  * allow  the  RLIMIT_NOFILE resource limit on the number of "in-
flight" file descriptors to  be  bypassed  when  passing  file
descriptors  to  another process via a UNIX domain socket (see
unix(7));
  * override the /proc/sys/fs/pipe-size-max limit when setting the
capacity of a pipe using the F_SETPIPE_SZ fcntl(2) command.
  * use  F_SETPIPE_SZ to increase the capacity of a pipe above the
limit specified by /proc/sys/fs/pipe-max-size;
  * override /proc/sys/fs/mqueue/queues_max  limit  when  creating
POSIX message queues (see mq_overview(7));
  * employ the prctl(2) PR_SET_MM operation;
  * set  /proc/[pid]/oom_score_adj to a value lower than the value
last set by a process with CAP_SYS_RESOURCE.

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). So even though BIND drops some capabilities, it's
still running with elevated privileges compared to a traditional
non-root user.

systemd permits a nice pattern for network daemons that want to run as
an unprivileged user, but bind to a privileged port (and without using
socket activation), without starting the process as root. Basically, you
put something like this in the unit file:

[Service]
User=…
Group=…
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT CAP_SETPCAP
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT CAP_SETPCAP
…

Any needed filesystem directories and permissions need to be set up
correctly before hand. The service is started by the init system as the
unprivileged User/Group specified in the unit file, so there's no need
to change UID/GID. CAP_NET_BIND_SERVICE is then used to bind to a
privileged port, CAP_SYS_CHROOT is used to perform the chroot, and
CAP_SETPCAP is used to drop all remaining capabilities from the
capability sets and the capability bounding set, so you end up with a
completely unprivileged process at runtime. (Alternatively you could
keep CAP_NET_BIND_SERVICE and drop CAP_SYS_CHROOT and CAP_SETPCAP, if
you wanted to retain the capability to perform privileged binds at
runtime. Or you could eliminate CAP_SYS_CHROOT and use other systemd
functionality to make parts of the filesystem inaccessible, etc.) This
pattern might be a bit hard to retrofit into BIND at this point, though,
other than by 

Re: Enable systemd hardening options for named

[Tony Finch]

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/unix/os.c;hb=v9_11_2#l234

Note that it's a bit clever - the privileges are dropped in two stages,
right at the start, and after the server has been configured.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Westerly 6 to gale 8, veering northwesterly 4 or 5 later,
occasionally severe gale 9 at first in south. Very rough in north, otherwise
high, occasionally very high in far south. Snow showers. Good occasionally
poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Enable systemd hardening options for named

[Reindl Harald]

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://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/systemd/man/systemd.exec.html#SystemCallFilter=


Where I could find the lists ?


you can not limit syscallfilter that way because every software or glibc 
update could change the used ones as well as previously unknown may get 
added like random generator recently - blacklisting them is the way to go


[root@srv-rhsoft:~/updateservice/subversion]$ cat 
/etc/systemd/system/named.service

[Unit]
Description=DNS Server
After=network.service systemd-networkd.service network-online.target 
network-wan-bridge.service network-wlan-bridge.service openvpn.service


[Service]
Type=simple
ExecStartPre=/usr/libexec/setup-named-chroot.sh /var/named/chroot on
ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z 
/etc/named.conf

ExecStart=/usr/sbin/named -4 -f -u named -t /var/named/chroot
ExecReload=/usr/bin/kill -HUP $MAINPID
ExecStop=/usr/bin/kill -TERM $MAINPID
ExecStopPost=/usr/libexec/setup-named-chroot.sh /var/named/chroot off
TimeoutSec=25
Restart=always
RestartSec=1

PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_SYS_ADMIN 
CAP_DAC_OVERRIDE CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_BROADCAST CAP_NET_RAW CAP_IPC_LOCK CAP_SYS_CHROOT
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime 
delete_module fanotify_init finit_module get_mempolicy init_module 
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp 
kexec_load keyctl lookup_dcookie migrate_pages move_pages 
open_by_handle_at perf_event_open process_vm_readv process_vm_writev 
ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib 
vmsplice


ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users