Stubby latest patch fails to start 0.4.2-1 Arch Plasma-Dev FIX

[Archcan]

After receiving the latest update 0.4.2-1 last week, Stubby fails to start. Plasma-dev Arch. New fresh install with latest daily ISO gives the same result.

Output:
systemctl status stubby
× stubby.service - stubby DNS resolver
    Loaded: loaded (/usr/lib/systemd/system/stubby.service; enabled; preset: disabled)
    Active: failed (Result: exit-code) since Mon 2022-11-28 12:32:18 EST; 11min ago
  Duration: 67ms
   Process: 1336 ExecStart=/usr/bin/stubby (code=exited, status=1/FAILURE)
  Main PID: 1336 (code=exited, status=1/FAILURE)
       CPU: 60ms

Nov 28 12:32:18 as systemd[1]: stubby.service: Scheduled restart job, restart counter is at 5.
Nov 28 12:32:18 as systemd[1]: Stopped stubby DNS resolver.
Nov 28 12:32:18 as systemd[1]: stubby.service: Start request repeated too quickly.
Nov 28 12:32:18 as systemd[1]: stubby.service: Failed with result 'exit-code'.
Nov 28 12:32:18 as systemd[1]: Failed to start stubby DNS resolver.

Not a Kernel issue (6.0-10 0r 6.1-rc7 is same):

Operating System: Manjaro Linux BTRFS
KDE Plasma Version: 5.26.80 >5.26.4 beta
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
Kernel Version: 6.1.0-1-MANJARO (64-bit) >rc-7
Graphics Platform: Wayland
Processors: 8 × AMD Ryzen 7 2700U with Radeon Vega Mobile Gfx

[ArchangeGabriel]

Can you share your stubby configuration? I don’t have issues here.

[archFriendly]

Same issue here after upgrading to 0.4.2-1 on two Arch machines with identical Stubby configurations. Downgrading to 0.4.0-2 restores functionality.

I see this error after upgrading to 0.4.2-1 and running journalctl:
error: Could not bind on given addresses: Permission denied

Stubby then fails to start with the exit code Archcan posted.

---

(edit - Resolved?)

The workaround posted below will get Stubby 0.4.2-1 to start for me, but I'm not sure if that's an acceptable or secure thing to do.

Private users prevents running on systemd #324

[Archcan]

Sorry for the delay! I tested positive to COVID 19 the day I posted the bug. In the config, I never go there, stubby runs after enabling its service.

The parameter PrivateUsers is already there. We must change it to false and it triggers systemd. Thanks for reporting the solution mate.

Please give consideration to a permanent solution. I don't think anyone's asking you to think.

stubby.service in systemd: edit unit file

[Unit]
Description=stubby DNS resolver
Wants=network-online.target
After=network-online.target

[Service]
Restart=on-failure
RestartSec=1
User=stubby
DynamicUser=yes
CacheDirectory=stubby
WorkingDirectory=/var/cache/stubby
ExecStart=/usr/bin/stubby
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
LockPersonality=true
MemoryDenyWriteExecute=true
NoNewPrivileges=true
PrivateDevices=true
PrivateTmp=true
PrivateUsers=false
ProtectClock=true
ProtectControlGroups=true
ProtectHome=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectProc=invisible
ProtectSystem=strict
RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK AF_UNIX
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

[Install]
WantedBy=multi-user.target

[ArchangeGabriel]

Alright, this is indeed a classical issue of CAP_NET_BIND_SERVICE + PrivateUsers=True. I think we should then makes Stubby the most secure possible by default (so no Cap and PrivateUsers), and document that people wanting to bind on a low port need to override these three settings. OTOH, it means the OOTB configuration does not work, which is not very good either… but the default configuration is not a good idea as it makes Stubby the default resolver without caching being available. I guess Stubby should be made listening to some high port by default (e.g. 8053) to force people looking into configuring a caching resolver in front or deliberately choose not do so.

[Archcan]

Are you suggesting to delete both CAP_NET_BIND_SERVICE and PrivateUsers? If the case, Stubby fails to start again.

This is the only solution: PrivateUsers=false

This is not a classical issue here, it's the first time ever that we have a bug with Stubby (Arch or Debian) and it comes from the last upgrade: 0.4.2.1. This version is just a waste of time and energy.

[molitona]

same issue on ArchLinux, fix it please!!!

[ArchangeGabriel]

Are you suggesting to delete both CAP_NET_BIND_SERVICE and PrivateUsers? If the case, Stubby fails to start again.

No, I’m saying that we should have the default as

AmbientCapabilities=
CapabilityBoundingSet=
PrivateUsers=true

and that all the people hitting issues because of this should know that Stubby does not do caching, and if they really want it to directly answer on port 53, then they also need to setup a systemd override as:

AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
PrivateUsers=false

And by classical issue, I mean that PrivateUsers=True negating CAP_NET_BIND_SERVICE is not knew, see e.g. https://bugs.archlinux.org/task/65921 or even better https://wiki.archlinux.org/title/Gitea#Binding_on_restricted_ports. I’m leaning towards the same documentation for Stubby, but I need a comment from either @saradickinson or @wtoorop to know whether that would makes sense for Stubby default to not be binding on 53 so that people look into caching.

[wtoorop]

Thanks @ArchangeGabriel , Noted! I'll study this soon. One question: Would dropping user privileges from the Stubby process help and make it easier?

[saradickinson]

@wtoorop @ArchangeGabriel My proposal is a quick fix that reverts to PrivateUsers=False. Not ideal but it is the least disruption as it reverts to the 0.4.0 situation (I do know of many users binding to port 53).

Then @wtoorop and I can look at the longer term solution for the next release with appropriate documentation/warnings!

[Archcan]

Thanks for replying and sorry for being rude.
This is the only solution.

AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
PrivateUsers=false

Changes made to stubby in systemd must be followed by this:

systemctl daemon-reload
systemctl start stubby
systemctl status stubby

In my case, there is no way to revert to previous because of the plasma-dev daily build (the cache is empty). No big deal since false works fine. Thanks again for considering a permanent solution and happy holiday.

[johndickinson]

@wtoorop You could drop privileges but that kind of defeats all the benefit of using DynamicUser

[johndickinson]

Removing PrivateUsers only changes the security analysis score from 1.5 OK to 1.7 OK. Note that this "security" score is more like a measure of how much systemd functionality is being used

[Archcan]

Version 0.4.2-3 fixes it. We are back to 0.4.0-x and there is no modification to be made. Thanks for the correction.

[saradickinson]

Closing this as addressed by 0.4.3 release