Le 06/02/2021 à 21:03, Geo Kozey a écrit :
From: Archange via arch-general <arch-general@xxxxxxxxxxxxxxxxxxx>
Sent: Sat Feb 06 17:51:25 CET 2021
Le 06/02/2021 à 20:00, Archange via arch-general a écrit :
Le 06/02/2021 à 18:51, Genes Lists via arch-general a écrit :
Now I can get nsd to start up, but get this problem:
nsd[10230]: setsockopt(..., IP_TRANSPARENT, ...) failed for tcp:
Operation not permitted
So if you use this option (IP_TRANSPARENT), which is non-default, you
might want to add a service drop-in extending CapabilityBoundingSet to
also include CAP_NET_ADMIN. Since I expect this to be a non-standard use
case, I’d prefer to not add it by default and rather document it on the
wiki.
I disagree with downstream hardening efforts that limit app features (even when
they aren't default) and passing the burden of making things work to users.
Security should be transparent and not block legitimate app usage. I recommend
to add relevant capability to systemd service. This was done for unbound when
similar issue popped out.
I do not agree with this in the general case, e.g. here we are talking
about a niche feature (we agreed with Genes that this was actually not
the correct solution to their issue), that moreover seemed to required
CAP_NET_ADMIN at first sight, which opens a large attack surface. For
me, this is the kind of things that should be properly documented on the
wiki rather than being enabled when only a tiny fraction of users will
in fact require it. This is Arch Linux, we are talking server software
here, I expect people to be able to read some doc and wanting the most
reasonable security level by default.
That being said, in the precise case they are two things to be considered:
1. CAP_NET_RAW is actually sufficient and has a way lower attack
surface, also as you mentioned it this is actually what is in use inside
unbound.service.
2. We already have to disable the capabilities incompatible
PrivateUsers=true that would otherwise be only needed by this (and would
have been a large enough blocker for me), since I agree that disabling
CAP_NET_BIND_SERVICE when we are talking of a server that is supposed to
run on port 53 by default and in likely most configurations would be dumb.
So, I’ll have ip_transparent working by default, now I just need to find
why capabilities are failing with ProtectSystem=strict but not with
ProtectSystem=full…
Regards,
Bruno/Archange
