FS#49881 - [dnscrypt-proxy] Consider adding a separate system user

Attached to Project: Community Packages
Opened by Alif (alive4ever) - Wednesday, 29 June 2016, 04:01 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 05 April 2018, 02:39 GMT
Task Type Feature Request
Category Security
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:
The upstream provided dnscrypt-proxy.server did not include a separate user. It would be safer to drop root privilege after starting dnscrypt-proxy service. This is available with '-u' switch.

Additional info:
* package version(s): dnscrypt-proxy 1.6.1-1
* config and/or log files etc.


Steps to reproduce:
1. Install dnscrypt-proxy.
2. Terminate/kill any dns forwarder/server process listening on 127.0.0.1 port 53
3. Start dnscrypt-proxy.service
4. Run ps and search for dnscrypt-proxy process. 'ps aux | grep dnscrypt-proxy'
5. dnscrypt-proxy doesn't drop root privilege.

I've attached some diff files to fix this problem. Tested and build fine in clean systemd-nspawn container chroot.



   pkgbuild-fix.diff (1.5 KiB)
   add-dnscrypt-user.diff (1.2 KiB)
   dnscrypt-userstart.diff (0.4 KiB)
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Thursday, 05 April 2018, 02:39 GMT
Reason for closing:  Won't implement
Additional comments about closing:   FS#57027  obsoletes this
Comment by Alif (alive4ever) - Wednesday, 29 June 2016, 04:05 GMT
Patches description:
pkgbuild-fix.diff : this patch is to be applied on PKGBUILD
add-dnscrypt-user.diff : this patch is to be applied on dnscrypt-proxy.install
dnscrypt-userstart.diff : this patch is part of source files (see patched PKGBUILD), automatically applied in the prepare() stage of makepkg.

Comment by Jakub Klinkovský (lahwaacz) - Wednesday, 29 June 2016, 05:26 GMT
The new user/group should get a fixed UID/GID in the database: https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database

The install file can be based on other packages doing similar things, e.g. pdnsd: https://git.archlinux.org/svntogit/community.git/tree/trunk/pdnsd.install?h=packages/pdnsd
Comment by Alif (alive4ever) - Wednesday, 29 June 2016, 07:32 GMT
If a fixed UID/GID is needed, I let the maintainer to make modification to the patches I attached, or even discard my patches, as long as the purpose for running dnscrypt-proxy under its own uid/gid is achieved.

Let the package maintainer choose the required UID/GID.
Comment by jk (jk) - Friday, 12 August 2016, 15:14 GMT
+1
Comment by I Said Socks (socks) - Sunday, 28 August 2016, 08:08 GMT
While `ExecStart=/usr/bin/dnscrypt-proxy --user=` is better than running as root, the best would be not to exec it as root in the first place.

I suppose root is only needed for binding to port 53, but as explained in its man page, dnscript-proxy isn't meant to run as a name server since it doesn't do caching,we should simply change the port :53 to some unprivileged port in dnscript-proxy.socket && we don't need to run it as root ever.

And then, we can add `User=dnscrypt` to the [Service] section in the service file instead.
Comment by David Runge (dvzrv) - Thursday, 29 December 2016, 20:07 GMT
what socks said.

I think it would be great to have a proper systemd integration, although it doesn't seem to play nice with the current dnscrypt-proxy config file.
If a separate user in the service file is used, the "User" setting in the configuration file can't be used.

Making port 5353 the default for dnscrypt is a good choice, too, as direct access doesn't make sense.
Comment by Jakub Klinkovský (lahwaacz) - Thursday, 29 December 2016, 20:35 GMT
You'll get similar behaviour with the LocalAddress option too: https://github.com/jedisct1/dnscrypt-proxy/issues/528
Comment by rdeckard (rdeckard) - Wednesday, 25 January 2017, 14:05 GMT
The service can use a privileged port by adding "CapabilityBoundingSet=CAP_NET_BIND_SERVICE" to the service file. Therefore the proposed modifications to the service file would be:

[Service]
User=dnscrypt
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

Although many users will change the port (to an unprivileged one) so they can use a local dns cache, but this will mean that the service will work with the default settings (once the user is added).
Comment by Jonathan Engbert (ejno) - Thursday, 30 November 2017, 02:44 GMT
dnscrypt-proxy has since added support for caching, so it seems suitable for use as a local name server.

The current configuration uses a systemd socket, so no privileges/capabilities are necessary for it to bind to the associated port (53 by default) if it's started under another user.

The new DynamicUser=yes option in systemd seems suitable here to me.

So, it appears that now the only change needed is to add the following line to the [Service] section of dnscrypt-proxy.service:
DynamicUser=yes
Comment by David Runge (dvzrv) - Tuesday, 02 January 2018, 17:20 GMT
Can alternatively a systemd-sysusers file be shipped?
Comment by Eli Schwartz (eschwartz) - Wednesday, 07 February 2018, 18:00 GMT
How does this fit in with the totally rewritten version 2.x mentioned in  FS#57027 ?
Comment by Ike Rippin (Janick.Hauck92) - Saturday, 24 March 2018, 13:36 GMT
@eschwartz DynamicUser fits perfectly, you can test with https://aur.archlinux.org/packages/dnscrypt-proxy-go/

Loading...