Run as non-root

[geofft]

It occurs to me there's no particular reason to keep running as root (at least on most systems, though for certain nss_ldap configurations, you've got a password that's readable only as root). We should support dropping privileges.

I think best practice is to run as your own system account instead of nobody because that quickly turns nobody into a fairly juicy target of its own, so probably this wants to be an argument to drop privileges to a specific user + some packaging config to create a system user.

[catern]

Isn't this trivially supported by using systemd socket activation? If nsncd uses systemd socket activation then it can just run with User=nobody or User=nsncd, it never needs root.

[leifwalsh]

Yeah but #9

[catern]

How about having systemd pass the socket down, but not socket activating it? i.e. nscd started up immediately rather than only on connection to the socket, but the socket is still passed down. I don't recall exactly how to configure that in systemd but it should be possible.

[geofft]

I think it's roughly equally as easy to just call setresuid (and setgroups(0, NULL)?) ourselves. We'd still probably use systemd-sysusers to create the user (assuming it does actually work properly on Debian, which I think it does).

I continue to worry about cases where systemd has the nscd socket open and receiving connectons, indicating to libc that nscd is worth trying, but nothing is actually accepting connections from the socket.

[catern]

On May 20, 2021 21:08, Geoffrey Thomas ***@***.***> wrote: I think it's roughly equally as easy to just call setresuid (and setgroups(0, NULL)?) ourselves. We'd still probably use systemd-sysusers to create the user (assuming it does actually work properly on Debian, which I think it does).

Maybe, but it's always preferable for privileges to be dropped before executing code, rather than relying on the code to sandbox itself after starting with privileges. A systemd unit can be inspected, and replaced with another sandboxing approach; not so with code inside nsncd.

I continue to worry about cases where systemd has the nscd socket open and receiving connectons, indicating to libc that nscd is worth trying, but nothing is actually accepting connections from the socket.

I don't think this would happen if systemd opens the socket immediately before starting nsncd.

[geofft]

What happens if systemd opens the socket immediately before starting nsncd, attempts to look up the non-root user to drop privileges to, and then deadlocks on itself?

That's very close to what happened in #9. ((I think systemd has some sort of explicit workaround for this scenario, but given the discussions in the two linked threads and the claims made about NSS and early boot, I wouldn't trust it.)

[catern]

In that scenario the fact that glibc stores whether nscd is usable after the first try saves us.

[geofft]

It stores it per process (in a global), and presumably systemd forks before attempting to drop privileges (lest it drop privileges of pid 1), so I don't think we can count on that. And if it does the lookup from pid 1, then pid 1 (which is single-threaded) stalls for five seconds, which isn't great.

Basically, assuming that this will work is a sizable production risk, closely related to risk that we've previously gotten burned by, for no obvious benefit (yes, in theory, you can inspect what the systemd unit file does, but in practice, having tried to read that code, you can't... and if you do want to inspect what nsncd does, the code for that is right there).

[flokli]

On NixOS, I successfully run nsncd as a non-root user, with effectively the following directives in [Service]:

[Service]
ExecStart=/path/to/bin/nsncd
User=nscd
Group=nscd
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=read-only
ProtectSystem=strict
RemoveIPC=true
Restart=always
RestrictSUIDSGID=true
RuntimeDirectory=nscd
Type=notify # needs #35

The nscd user is defined in /etc/fstab.

This works fairly well, and doesn't rely on any socket activation.

The RuntimeDirectory=nscd directive causes systemd to create/chown /run/nscd to be write-able by the User specified, and as /var/run is a symlink to /run (at least in our case), nsncd has enough permissions to create /var/run/nsncd/socket.

[geofft]

Oh, yes, I think that making /run/nscd owned by the non-root user should work, good point!

[leifwalsh]

are we done here?

[flokli]

We can probably update the unit file in the repo and/or add some docs about rootless operation.

[flokli]

I ported the unit file changes over in #110, though the Debian packaging bits need some more work probably.