Skip to content
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 /etc/shadow #41

Closed
rndmh3ro opened this issue May 23, 2016 · 7 comments
Closed

permissions /etc/shadow #41

rndmh3ro opened this issue May 23, 2016 · 7 comments

Comments

@rndmh3ro
Copy link
Member

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.

In my opinion we should follow the operating-system standards here.
On rhel-based systems the os-standards are even safer than the standards in this repo.

@chris-rock
Copy link
Member

cc @atomic111

@atomic111
Copy link
Member

@fitz123
Copy link

fitz123 commented May 24, 2016

So after reading all comments I didn't find requirements to grant write permissions on this file. Everywhere told it needs owner root group shadow and at least read permission for owner. @conorsch 's issue is lack of read permission for group in case desktop manager is used. I propose to check is XDG_SESSION_DESKTOP env variable set and if so, add read perm for group. If there's no such var as XDG_SESSION_DESKTOP - just do whatever we currently do

@rndmh3ro
Copy link
Member Author

Two things @fitz123:

I'm on Arch Linux right now, with a desktop manager and the XDG_SESSION_DESKTOP variable is empty, so this approach seems not to be the best one.

Also I don't want to introduce more complexity for such an edge-case (the main use-case for these hardening-roles is on servers where no desktop manager should be installed).

I'd like to follow what @atomic111 said in dev-sec/ansible-collection-hardening#86 (comment):
Just make the permissions and owner/group configurable. We leave the default values as they currently are (root,root 0600), but if the user wants to change them, he can do so.

@fitz123
Copy link

fitz123 commented May 25, 2016

default values works great for me as well. Simplest way is almost always better one =)

p.s. could you please check $XDG_CURRENT_DESKTOP var for me? It's interesting to find an easy way to detect dm, at least with some probability)

@conorsch
Copy link

Sounds like the consensus is:

  1. default to root:root 0000 (note: the role currently sets root:root 0600).
  2. permit full owner/mode overrides via a dict var

That solution would certainly work for my use case, but it seems a bit illogical from the standpoint of the role. @rndmh3ro's point that:

In my opinion we should follow the operating-system standards here.

sounds like the sane approach in the context of this hardening role. Can anyone formulate a a compelling argument that root:shadow 0640 is "wrong" for Debian-based systems? Administering headless Debian servers never showed this error for me (presumably because the SSH config wasn't using PAM), but on desktops it makes sense to honor on the setgid flag on unix_chkpwd, which is arguably superior to using setuid root on that same file.

@conorsch
Copy link

The implementation in dev-sec/ansible-collection-hardening#89 preserves the current behavior of root:root 0600, but permits overriding via a dict var. That should make everyone happy. If it gets merged, this issue can be closed without action, since the tests will not need to be updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants