-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harden nsncd.service #156
Comments
|
I'd be happy to review a change and read enough docs to understand it, but I don't actually feel familiar enough with systemd to attempt the change on my own, or at least, I could try but I have a feeling you'd do a better job if you know enough to file this. Any chance you'd like to send a PR? |
A lot of these seem like they ought to be irrelevant, or trivial to enable, for a service that runs as non-root + no ambient caps + NoNewPrivs. For instance, we have no ability to ever gain any of the caps in the bounding set, so the bounding set may as well be empty. We therefore have no ability to read/write kernel logs since we cannot ever gain the caps needed to use /dev/kmsg or /proc/kmsg, so whether we can see those files is irrelevant. (Without NoNewPrivs there would be an argument that an exploited service can pivot to invoking or attacking a setuid program like sudo, but setuid doesn't work under NoNewPrivs.) Has NixOS discussed automatically turning most of these on if a service runs as a non-root user with no ambient caps and NoNewPrivs? I think you could do this systematically. (I also think that the practical benefit of flipping all these knobs on is basically nil; any exploit that puts an attacker in a position to write to the NoNewPrivs flag or the kernel UID field for your process's kernel data structure is also going to put an attacker in a position to regain most of these without much more difficulty. So I'm a little surprised that upstream systemd-analyze bothers to report on those things. Reducing protocols, system calls, etc. makes sense because they actually limit attack surface.) One problem with coming up with a list of restrictions for nsncd is that it depends a lot on what the third-party NSS modules are and what they do. Generally you use nsncd because you have some interesting NSS config, whether that's an enterprise LDAP or SSSD setup, Avahi, nss_systemd, nss_docker, nss_libvirt, etc., and in turn that module will need to get its data from somewhere, usually the network. It may also have dependencies on other libraries and config on the system, other running daemons specifically for the NSS module (as in the case of SSSD, nss_ldapd, and winbind IIRC), or other running services on the system (in the case of nss_systemd, nss_docker, nss_libvirt, etc.). So while, for instance, nsncd technically doesn't do any network access on its own, we can't restrict network access. Of the X marks above, here's my quick thoughts:
If you're in a position to either let users choose between multiple hardening profiles or automatically determine what is needed and unneeded by the specific NSS libraries in use, you can probably be more aggressive with the settings. |
Where the authors are probably most familiar with what access is required, it would be nice if the
nsncd.service
file was updated with a good and secure default hardening setup.When the service is running on NixOS there is some hardening applied, but the service still gets a rating of
8.2 EXPOSED 🙁
insystemd-analyze security nscd.service
. The existing hardening is available here (here's another users config), and is obviously not very strict.There is an issue in the Nix repo focused on hardening system services. While hopefully someone will pick up
nsncd
it would probably be better if the info was available here.The text was updated successfully, but these errors were encountered: