Nixpkgs: Many of our NixOS services run as root and shouldn't

[copumpkin]

Ideally, they'd also be AppArmor'd and so on, but at the least they should get their own users, ideally in a way that we don't have to go manually add users for each individual service.

Anyone have a list of those modules handy so we can make this issue into a checklist? If not, I'll try to compile one later.

[vcunat]

Our X server version in particular is said to be capable of running root-less with systemd.

[DamienCassou]

Related to #14645

[spacekitteh]

Has the X server issue in particular been fixed?

[rnhmjoj]

Many services need to bind to a port < 1024 and require either running as root (and maybe dropping the privileges), some iptables forwarding trick or a capabilities setting. This restriction was considered a security feature but actually makes things worse and it's still here basically for no other reason than the historical one. It can be disable in the kernel with

#define PROT_SOCK 0

What do you think about it?

[aneeshusa]

For services that support it, using socket activation (e.g. with systemd) is a really nice way to let a process use a port < 1024 (systemd will bind the port and spawn children on each connection).

I don't see why this restriction "makes things worse", so I would not want to disable it. E.g., I wouldn't want a rogue process to be able to bind on port 22! (Of course it's best to pin sshd servers' host keys to verify their identities via e.g. UserKnownHostsFile, but this is another good layer of defense.)

[groxxda]

What's wrong with net_bind capability for services that don't support socket activation?

[aneeshusa]

For services that don't support socket activation, I prefer iptables/nftables based forwarding. net_bind allows the service to bind to any privileged port, while with iptables/nftables it can only receive traffic from the pre-specified ports.

[rnhmjoj]

I don't see why this restriction "makes things worse"

In my opinion It makes things more complicated by requiring another step before running the program with really no benefit.

I wouldn't want a rogue process to be able to bind on port 22!

If sshd or some other server it's running already it won't be able to bind, and if there's none what's the problem with that? You shouldn't rely on the port number for security. You have to verify the fingerprint (for ssh) or a certificate (for a webserver).

[groxxda]

@spacekitteh with gnome 3.22 we can run x without root privileges (see #19081)
But making it work with all display managers is probably hard

[peterhoeg]

systemd version 232 will support dynamically created users for the lifespan of services:

Support for dynamically creating users for the lifetime of a service
has been added. If DynamicUser=yes is specified, user and group IDs
will be allocated from the range 61184..65519 for the lifetime of the
service. They can be resolved using the new nss-systemd.so NSS
module. The module must be enabled in /etc/nsswitch.conf. Services
started in this way have PrivateTmp= and RemoveIPC= enabled, so that
any resources allocated by the service will be cleaned up when the
service exits. They also have ProtectHome=read-only and
ProtectSystem=strict enabled, so they are not able to make any
permanent modifications to the system.

This sounds to me like it would solve this problem very elegantly.

[spacekitteh]

bump

[unode]

Regarding services binding to ports lower than 1024, there's also CAP_NET_BIND_SERVICE as described here. The command itself needs to be run as root but once done any user can launch the binary and have it bind lower ports.
It's also non-permanent so if the binary is replaced the permission is lost.

[peterhoeg]

@Unode, we do not need to fiddle with setcap. systemd will handle that: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

[mmahut]

Are there any updates to this issue, please?

[rnhmjoj]

It's now possible to run X rootless with #47773, though using a display manager still requires root.
Does anyone know if it's possible at all? The display manager needs root in order to login but it seems to me that the permission could be dropped once logged in.

[rnhmjoj]

If anyone's interested I found out about net.ipv4.ip_unprivileged_port_start sysctl option that can be set to 0 to remove the privileged port restriction.

I'll try to explain it again: the "security" mechanism is the following: "I'm talking to \, it must have root premissions, therefore it's secure". This only made sense 30-40 years ago: a hacker couldn't simply set up is own mainframe, become root and mitm your connection but in 2019 we have unix running on watches, being root is meaningless. The correct way to authenticate is to use public key cryptography.

Protecting these ports is only useful if, for example, you have a socket activated sshd and don't want untrusted local users to bind to port 22, basically jamming the connection. I don't know how common this is. Meanwhile if I want to fire up a one-time webserver I have to fiddle with, setcap (doesn't work for a script or any binary in the /nix/store because it's read only), or setup port forwarding with iptables. If I'm in a hurry I'll end up running it as root, and that's not good.

[joachifm]

@rnhmjoj for the one-time www server case, have you tested whether something like

nix run nixpkgs.busybox -c systemd-run --uid=nobody \
   --property=AmbientCapabilities=CAP_NET_BIND_SERVICE -r httpd -p 80 -f

works?

[rnhmjoj]

@joachifm I didn't know about that, thank you. Interestingly, someone just told me Apple removed the privileged ports in macOS 10.14: https://news.ycombinator.com/item?id=18302380.