Permissions on /etc/shadow can lock out GUI users

[conorsch]

The role restricts /etc/shadow to root:root 0400. That's fine for servers, but on desktops it causes GUI lockscreen logins to fail:

$ grep chpwd /var/log/auth.log
unix_chkpwd[21667]: password check failed for user (conor)

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.

[fitz123]

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.
As an option, if you have to detect is desktop environment used - you can check remote env variables XDG_SESSION_DESKTOP, XDG_CURRENT_DESKTOP or echo "$XDG_DATA_DIRS" | grep -Eo 'xfce|kde|gnome', or together to see if desktop is used

[conorsch]

@fitz123 I'm using i3 as WM, with i3lock as screenlocker. Here are some relevant env vars:

$ printenv | grep -i desktop | sort
DESKTOP_SESSION=i3
XDG_CURRENT_DESKTOP=i3
XDG_DATA_DIRS=/usr/share/i3:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_DESKTOP=i3
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0

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.

[rndmh3ro]

The default permissions for /etc/shadow are:

• Debian/Ubuntu:

root@986e440df792:/home/kitchen# ll /etc/shadow
-rw-r----- 1 root shadow 683 May 23 15:43 /etc/shadow

see https://help.ubuntu.com/community/FilePermissions

• RHEL:

[root@b5704779e84f kitchen]# ll /etc/shadow
---------- 1 root root 670 Mar 23 17:20 /etc/shadow

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:

Passwords must be stored only as hashes (bcrypt, scrypt), never in clear text. Files containing password hashes must be protected against unauthorized access.

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:
https://github.com/dev-sec/tests-os-hardening/blob/master/controls/os_spec.rb#L33-L48

The results will then be implemented.

[rndmh3ro]

dev-sec/linux-baseline#41

[atomic111]

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?

[conorsch]

I'm happy to submit a PR making the file map (owner, group, mode) configurable via vars. For now I will stick to the default behavior currently present in the role, although discussion is ongoing in dev-sec/linux-baseline#41, and the default behavior may change as a result.

[conorsch]

@atomic111 Implemented override capability per your suggestion. The default config of root:root 0600 remains unchanged, but now users of the role can customize.