Skip to content
This repository has been archived by the owner on Apr 6, 2021. It is now read-only.

Root only accessible secret files #51

Closed
ThomasHabets opened this issue Oct 10, 2014 · 6 comments
Closed

Root only accessible secret files #51

ThomasHabets opened this issue Oct 10, 2014 · 6 comments

Comments

@ThomasHabets
Copy link
Contributor

Original issue 51 created by oh8glu on 2011-03-16T19:32:03.000Z:

What steps will reproduce the problem?

  1. Enable pam_google_authenticator.so for sudo with secret=/var/spool/google-authenticator/${USER}
  2. mkdir var/spool/google-authenticator ; chmod 700 /var/spool/google-authenticator
  3. mv ~user/.google-authenticator /var/spool/google-authenticator/user
  4. sudo -l as user

What is the expected output?
Prompt for password and verification code

What do you see instead?
Mar 16 20:24:21 host sudo(pam_google_authenticator)[23453]: Failed to read "/var/spool/google-authenticator/user"
Mar 16 20:24:23 host sudo: user : pam_authenticate: Cannot make/remove an entry for the specified session ; TTY=pts/2 ; PWD=/ ; USER=root ; COMMAND=list

What version of the product are you using? On what operating system?
version: hg after commit 53:a680ec2a1fc9
os: Debian squeeze

Please provide any additional information below.
The pam module should include an option to allow the secret file to be operated by root (only).
This way the user does not have direct read/write access to the file and stealing or tampering with the secret would be more difficult.

The attached patch disables drop_privileges and allows the secret file to be owned by root.

@ThomasHabets
Copy link
Contributor Author

Comment #1 originally posted by kroot@google.com on 2011-03-16T19:54:54.000Z:

Limiting access to just me doesn't seem to be the solution :-)

@ThomasHabets
Copy link
Contributor Author

Comment #2 originally posted by oh8glu on 2011-03-16T20:13:52.000Z:

The point of the patch is to support a scenario where the OTP password is used for additional verification in sudo. Here if the user has access to the secret, the OTP does not provide any additional security since the attacker could just read (or overwrite) the secret.

@ThomasHabets
Copy link
Contributor Author

Comment #3 originally posted by oh8glu on 2011-03-16T20:16:47.000Z:

To clarify, the attached patch only demonstrates the desired functionality but obviously this should be a configurable option for the pam module.

@ThomasHabets
Copy link
Contributor Author

Comment #4 originally posted by markus@google.com on 2011-03-18T11:25:49.000Z:

<empty>

@ThomasHabets
Copy link
Contributor Author

Comment #5 originally posted by dwmw2b on 2011-09-12T00:30:09.000Z:

This patch makes it configurable. I can now use a configuration such as:
auth sufficient pam_google_authenticator.so no-drop-privs secret=/etc/google-authenticator/${USER}

This probably ought to be the default behaviour. The current default behaviour of storing it in ~/.google-authenticator means that:

  • Any process running as the user can read the file and 'leak' the master key.
  • Any process running as the user can change the master key.

Or to give the equivalent behaviour for normal passwords, it's like the passwd(8) program letting you change your password without entering the old one, and like having a separate passwd-reminder(8) which will just tell you your password if you've forgotten it, without any form of ID check first.

@ThomasHabets
Copy link
Contributor Author

Comment #6 originally posted by markus@google.com on 2011-12-15T08:47:19.000Z:

The "user=" option should give you the feature that you asked for. Please re-open this issue, if you need additional work.

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

No branches or pull requests

1 participant