[arch-general] nsd 4.3.5 broken

[Archange]

Le 06/02/2021 à 21:03, Geo Kozey a écrit :
>> From: Archange via arch-general <arch-general at lists.archlinux.org>
>> 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