Store passwords required by a linux daemon

问题:

I have written a linux daemon that will be (and must be) running as root. When it runs, there will not necessarily be anyone logged in as it is started by cron. That daemon needs to store some urls, uids and passwords as it connects to other servers (such as dropbox, google, windows servers etc).

Q: What is the best place and method to store those passwords.

I can't store hashes as I need the original url/uid/pwd to connect to the remote services.

There are only two options that I can see:

a) gnome-keyring-daemon
As far as I can tell, this requires a logged in user/session. I have experimented with starting it from my daemon (as root), collecting the returned environment variables and attempting to connect to it. So far this has failed.
b) a read-only file owned by root.
This could also be encrypted using (for example) the hostid, but the bottom line is that this approach relies on obscurity and root access.

Are there other options?
Many thanks.

回答1:

The kind of people who are looking to steal passwords know how to root the OS. Do NOT rely on file permissions. That's like saying "please don't read this file. pretty please?"

You need to encrypt that stuff. Android has a keyring (search the api), you can use that, but it does require a password. Do NOT hardcode the password in your code, ask the user for one.

When you are dealing with your user's passwords, you have a responsibility. If you avoid that responsibility, they will lynch you someday.

edit: woah, sorry, i totally thought this was an android question. But still, use a keyring and strong crypto.

回答2:

You may take a look at the Application-to-Application Password Management feature available in ManageEngine Password Manager Pro.

The applications and scripts in your infrastructure that communicate with other applications using a password, can securely query Password Manager Pro to retrieve the password whenever they need.

Password Manager Pro (PMP) provides two flavors of API for this purpose:

1. a comprehensive application API based on XML-RPC over HTTPS and
2. a command line interface for scripts over secure shell (SSH)

Both the forms use PKI authentication for allowing access to the PMP application through the API. The XML-RPC API also comes with a Java Wrapper API to make it easy for integrating it with Java applications.

You may achieve your requirement using this feature.

For more info:

http://www.manageengine.com/products/passwordmanagerpro/help/application-to-application-password-management.html

回答3:

I faced this problem several times cause because people often gets confused with enterprise security recommendations.

People usually gets confused when having to implement a client certificate authentication for SSL and read the NO SELF-SIGNED CERTIFICATES ALLOWED because having the your own CA certificate signed by any external authority would not add anything.

People also gets confused with the recommendation to STORE USERS CREDENTIAL USING A SALTED HASH ALGORITHM with the need to store credentials for a daemon to access services like database servers or message brokers.

I always see the naïve solution to encrypt credentials with the password for the key being stored in plain text anywhere else in the software, which will only cause problems for system administrator but not for an invasor. Some time back I saw a software developer required to hash a generated key, store that hash in a text file and use that hash string as the key to encrypt/decrypt the file containing the credentials, the architect was unhappy until the actual key was a string that looked like a hashed password. Can you believe that?

You cannot rely on keyring/keychains for daemons, cause daemons should not be authentication on behalf of users, if they are impersonating users they should be agents and should use a keyring/keychain available on each OS environment.

回答4:

A read-only file owned by root is pretty much the recommended solution: important services such as openssh use that option.

回答5:

Have a google around for Privilege Identity Management products. Some examples are Cyber-Ark's suite:

http://www.cyber-ark.com/

Or Password Manager Pro:

http://www.manageengine.com/products/passwordmanagerpro/download.html

The advantage these tools have is that if the server is cracked the attacker then needs to work out how to retrieve the password from the password store (or grab it out of memory). This will be more time-consuming and hopefully give you a better chance to detect their intrusion. It should also be possible to identify it is a fraudulent request to the password store in cross-checking since it isn't linked to a transaction.

Another option would be to encrypt it on the disk and have the user have to enter a pass-phrase for a GPG key that unlocks the passwords. pwman, passwordsafe and other tools may support something like this if you can find a good API that can read/write their databases.

回答6:

1. Why does it need to run as root?
2. Why can't you enter the password as a non-root user?

Have you considered creating a long-running process that reads the keys (using the keyring), and then sleeps on a UNIX domain socket, waiting for a 'time to do your stuff' signal? Your cron job can simply wake this long-running process, by writing to the UNIX domain socket, without actually doing the work. (Thus your keys stay in memory the entire time). Moreover, rather than giving the long-running process root access, you could always make it fork() a subrocess and escalate its privilege to root in the subprocess to perform individual activities that require root access (without always being in that escalated state). If you make it a 'setuid' process (chown root:root, chmod u+s), then it can escalate to root level access as needed, even if executed by an ordinary user.