Repository navigation
Conversation
160e820 to
0b2b69f
Compare
e514bf4 to
2a51dca
Compare
This updates the nsncd.service systemd unit file to run nsncd as a `nscd` user and group, and enables sandboxing. Fixes twosigma#14.
4bc4486 to
a8844c6
Compare
a5160d5 to
6b28468
Compare
This is a debian patch and required to omit specific lookup types
geofft
left a comment
There was a problem hiding this comment.
I think we need to add adduser to Depends in debian/control. That probably also means it can be removed from the GHA script, since installing nsncd will pull it in as needed.
Other than that, LGTM. I worried a bit about whether there are any NSS modules in common use that require privileged subprocesses (analogous to how pam_unix runs unix_chkpwd to get access to /etc/shadow) and so the sandboxing would affect that, but I don't think there is. I asked Claude to scrape the Debian repos to see if there's any packaged NSS modules that include setuid/setcap binaries but it didn't find any, either. This doesn't rule out that there might be some private / enterprise NSS module that does this, but that seems unusual. A more common design for something needing privileged access is a local client/server architecture, which e.g. both nslcd and sssd use for LDAP credentials.
The one case I'm worried about is whether an existing site specifically using nsncd has accidentally configured their system so that NSS lookups only work as root, e.g., /etc/passwd with the wrong permissions, or more practically, something like nss-extrausers with the extrausers file being unintentionally root-only. But that would arguably be our fault for previously running as root and it seems worth breaking that ASAP, and there's no good way for us to detect/warn about this. If we have something like release notes, I might document that users should confirm that their setup works as non-root.
Do you know if Debian has a preference for a static system user vs. using systemd's dynamic users feature? I suppose the risk of UID reuse on /var/run/nscd/ argues a bit in favor of a static user. (Mostly I'm thinking that dynamic users would save us from having to think about adduser at all, and would work on all distros without them having to create the _nsncd user in their packaging.)
|
Re: Dynamic user, I don't think so, I actually reached out to the Debian maintainer Philipp who suggested the _nsncd user and group. |
Co-authored-by: Leif Walsh <leif.walsh@gmail.com>
| case "$1" in | ||
| configure) | ||
| # 1. Create a system group if it doesn't exist | ||
| if ! getent group "$_GROUPNAME" >/dev/null; then |
There was a problem hiding this comment.
I don't see $_GROUPNAME set anywhere
| case "$1" in | ||
| purge) | ||
| # Remove the system user if deluser exists and the user exists | ||
| if [ -x "$(command -v deluser)" ] && getent _nsncd >/dev/null; then |
| @@ -0,0 +1,34 @@ | |||
| #!/bin/sh -e | |||
|
|
|||
| set -e | |||
| configure) | ||
| # 1. Create a system group if it doesn't exist | ||
| if ! getent group "$_GROUPNAME" >/dev/null; then | ||
| addgroup --system --quiet _nsncd |
There was a problem hiding this comment.
you can remove this and specify --system --group in the adduser below
| RestrictNamespaces=true | ||
| SystemCallArchitectures=native | ||
|
|
||
| RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 |
There was a problem hiding this comment.
restricting AF_NETLINK breaks things such as nss-myhostname
|
Running as non-root is definitely an admireable goal, but there are some (largely legacy) plugins like the old libnss_ldap that actually do need to be run as root. nscd has an opt-in "server-user" to drop privs. Maybe there is nothing modern left that we care about? |
Building on top of
#110