-
Notifications
You must be signed in to change notification settings - Fork 729
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
Permissions on /etc/shadow can lock out GUI users #86
Comments
I'm not familiar with the topic, but you mentioned "screenlocker". What is it? Whatever it's, if this is the specific case - you can detect its present on the system and set variable accordingly. |
@fitz123 I'm using i3 as WM, with i3lock as screenlocker. Here are some relevant env vars:
Admittedly I use i3 on most graphical machines I have access to these days, so it may be i3-specific, but I would wager it affects Debian-like systems running Gnome or KDE as well. |
The default permissions for
see https://help.ubuntu.com/community/FilePermissions
see https://www.stigviewer.com/stig/red_hat_enterprise_linux_6/2013-02-05/finding/RHEL-06-000035 The Deutsche Telekom security assesment process (which this hardening project loosely follows) proposes:
Motivation: Passwords are in need of protection that only account owners or authorized persons may know and change. This measure is designed to ensure that unauthorized persons cannot gain knowledge of these passwords or have the chance to change them. Implementation example: For system passwords, the file /etc/shadow shall be used in Linux. For other operating systems, the respectiveequivalent file shall be used, which is only readable for the root and only contains the hashes of the systempasswords. I propose we talk about this issue in the test-os-hardening repository, here's the test: The results will then be implemented. |
thanks for bringing this up. we can introduce a chef, ansible or puppet attribute to make it configurable. the default value would be 0600 for /etc/shadow but then you can adjust it. @conorsch How does that sounds for you? |
I'm happy to submit a PR making the |
@atomic111 Implemented override capability per your suggestion. The default config of root:root 0600 remains unchanged, but now users of the role can customize. |
The role restricts /etc/shadow to root:root 0400. That's fine for servers, but on desktops it causes GUI lockscreen logins to fail:
The problem is that the screenlocker can no longer read /etc/shadow as the normal user. The setgid on /sbin/unix_chkpwd (2755 root:shadow) doesn't work with 0400 perms on /etc/shadow. Both Debian and Ubuntu expect /etc/shadow to be 0640 root:shadow. One workaround would be to adjust unix_chkpwd to setuid root, but that's a step backward from a hardening perspective.
For simplicity's sake, we can use the
os_desktop_enable
boolean to skip updating permissions on /etc/shadow when true. Then the role will continue to work as expected in headless environments (likely 95% of the use case for this role), and also be trivially reusable on interactive workstations.Another more complicated option is to provide custom logic that enforces root:shadow 0640 under Debian-like systems. I haven't tested Fedora and similar yet, so I don't know whether they will need a similar setup.
The text was updated successfully, but these errors were encountered: