Permissions on /etc/shadow can lock out GUI users about ansible-collection-hardening HOT 7 CLOSED

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

from ansible-collection-hardening.

@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.

from ansible-collection-hardening.

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.

from ansible-collection-hardening.

dev-sec/linux-baseline#41

from ansible-collection-hardening.

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?

from ansible-collection-hardening.

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.

from ansible-collection-hardening.

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

from ansible-collection-hardening.