[arch-general] nsd 4.3.5 broken
Good morning nsd package (4.3.5-1) in testing doesn't start for me. 4.3.4 works but 4.3.5 fails - lacks permission in the working directory. This is what log says: service: Changing to the requested working directory failed: Not a directory service: Failed at step CHDIR spawning /bin/kill: Not a directory service: Control process exited, code=exited, status=200/CHDIR The new service start file has: WorkingDirectory=~ I tried: WorkingDirectory=/etc/nsd but this still fails Thanks.
On 2/6/21 9:34 AM, Genes Lists via arch-general wrote:
I tried couple more things. I changed RunTimeDirecroy=/etc/nad # it was previosuly set to: =nsd Now I can get nsd to start up, but get this problem: nsd[10230]: setsockopt(..., IP_TRANSPARENT, ...) failed for tcp: Operation not permitted nsd[10230]: cannot open pidfile /run/nsd/nsd.pid: No such file or directory nsd[10230]: cannot overwrite the pidfile /run/nsd/nsd.pid: No such file or directory nsd[10230]: unable to initgroups nsd: Operation not permitted So the new permissions seem too strict. I confirmed this as If i put the 4.3.4 nsd.service into /etc/systemd/system then 4.3.5 starts up and works fine. Bruno can you help get this sorted out please? thanks gene
Le 06/02/2021 à 18:51, Genes Lists via arch-general a écrit :
On 2/6/21 9:34 AM, Genes Lists via arch-general wrote:
I tried couple more things.
I changed RunTimeDirecroy=/etc/nad # it was previosuly set to: =nsd
Now I can get nsd to start up, but get this problem:
nsd[10230]: setsockopt(..., IP_TRANSPARENT, ...) failed for tcp: Operation not permitted nsd[10230]: cannot open pidfile /run/nsd/nsd.pid: No such file or directory nsd[10230]: cannot overwrite the pidfile /run/nsd/nsd.pid: No such file or directory nsd[10230]: unable to initgroups nsd: Operation not permitted
So the new permissions seem too strict.
I confirmed this as If i put the 4.3.4 nsd.service into /etc/systemd/system then 4.3.5 starts up and works fine.
Bruno can you help get this sorted out please?
Yes of course, it’s not like I sent an email to you personally to tell you about the changes and that breaking was expected, so that tests of the package in [testing] was welcome. ;) Regarding the first issue, what if you change WorkingDirectory (to WorkingDirectory=/etc/nsd for instance, or maybe /run/nsd/) instead? I’m looking into initgroups and IP_TRANSPARENT meanwhile. Bruno/Archange
On 2/6/21 11:00 AM, Archange wrote:
Regarding the first issue, what if you change WorkingDirectory (to WorkingDirectory=/etc/nsd for instance, or maybe /run/nsd/) instead?
Thanks for follow up. Tried that - didn't solve the chdir permission issue. I wasnt sure if "~" referred to root or nsd - hence chaged to /etc/nsd. But didnt help. Also logged it here: https://bugs.archlinux.org/task/69566
I’m looking into initgroups and IP_TRANSPARENT meanwhile.
Thank you again.
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 :
On 2/6/21 9:34 AM, Genes Lists via arch-general wrote:
I tried couple more things.
I changed RunTimeDirecroy=/etc/nad # it was previosuly set to: =nsd
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.
nsd[10230]: cannot open pidfile /run/nsd/nsd.pid: No such file or directory nsd[10230]: cannot overwrite the pidfile /run/nsd/nsd.pid: No such file or directory
This is because you changed the RuntimeDirectory, which should not be touched.
nsd[10230]: unable to initgroups nsd: Operation not permitted
This is harmless, it happens because nsd thought to be root and tried to give up rights, but I’m not starting nsd as root anymore with the new service, so actually this is just a warning and expected.
So the new permissions seem too strict.
I confirmed this as If i put the 4.3.4 nsd.service into /etc/systemd/system then 4.3.5 starts up and works fine.
Bruno can you help get this sorted out please?
Yes of course, it’s not like I sent an email to you personally to tell you about the changes and that breaking was expected, so that tests of the package in [testing] was welcome. ;)
Regarding the first issue, what if you change WorkingDirectory (to WorkingDirectory=/etc/nsd for instance, or maybe /run/nsd/) instead?
Actually removing the line entirely is the better solution, I thought I had done it after removing the $home from the nsd user, but apparently not. Pushed 4.3.5-2 to [community-testing] with that change, continuing on the bug tracker for further debugging. ;) Regards, Bruno/Archange
---------------------------------------- From: Archange via arch-general <arch-general@lists.archlinux.org> Sent: Sat Feb 06 17:51:25 CET 2021 To: General Discussion about Arch Linux <arch-general@lists.archlinux.org> Cc: Archange <archange@archlinux.org> Subject: Re: [arch-general] nsd 4.3.5 broken
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 :
On 2/6/21 9:34 AM, Genes Lists via arch-general wrote:
I tried couple more things.
I changed RunTimeDirecroy=/etc/nad # it was previosuly set to: =nsd
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. Yours sincerely G. K.
On 2/6/21 12:03 PM, Geo Kozey via arch-general wrote:
---------------------------------------- From: Archange via arch-general <arch-general@lists.archlinux.org> ...
nsd[10230]: setsockopt(..., IP_TRANSPARENT, ...) failed for tcp: Operation not permitted
So if you use this option (IP_TRANSPARENT), which is non-default, you ... I disagree with downstream hardening efforts that limit app features (even when .. G. K.
Yes i am using ip-transparent - this is pretty helpful option to avoid non-starting when network unavailable for some reason. I would also prefer that CAP_NET_ADMIN be added as default config. thanks.
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
On 2/6/21 3:28 PM, Archange via arch-general wrote:
...
So, I’ll have ip_transparent working by default, ...
Regards, Bruno/Archange
Closing the loop here (bug report also closed). The latest package in testing (4.3.5-3) works out of the box - including supporting ip-transparent and priv. ports. The update makes nsd far and away more secure - thank you Bruno - yoru efforts are very much appreciated. regards, gene
participants (3)
-
Archange
-
Genes Lists
-
Geo Kozey