Le 06/02/2021 à 21:03, Geo Kozey a écrit :
From: Archange via arch-general <arch-general@lists.archlinux.org> Sent: Sat Feb 06 17:51:25 CET 2021
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
Le 06/02/2021 à 20:00, Archange via arch-general a écrit : 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