Store Passwords Required by a Linux Daemon

Store passwords required by a linux daemon

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

Storing encrypted passwords storage for remote linux servers

In my opinion using key authentication is the best and safest in my opinion for the SSH part and is easy to implement.

Now to the meat of your question. You want to store these keys, or passwords, into a database and still be able to use them. This requires you to have a master password that can decrypt them from said database. This points a point of failure into a single password which is not ideal. You could come up with any number of fancy schemes to encrypt and store these master passwords, but they are still on the machine that is used to log into the other servers and thus still a weak point.

Instead of looking at this from the password storage point of view, look at it from a server security point of view. If someone has access to the server with the python daemon running on it then they can log into any other server thus this is more of a environment security issue than a password one.

If you can think of a way to get rid of this singular point of failure then encrypting and storing the passwords in a remote database will be fine as long as the key/s used to encrypt them are secure and unavailable to anyone else which is outside the realm of the python/database relationship.

Password management in Bash

There are 2 ways I can think of safely approaching this problem.

1. GPG

Keep a GPG encrypted file with your passwords in it in key=value format (shell parsable basically), one per line. Such as:

foo_pass='bar'
pop_pass='tart'

When you want to access them, just do:

eval "$(gpg -d /path/to/file | grep '^foo_pass=')"
SUPERSECRETPASSWORD="$foo_pass" somecmd

If the command needs the password as an argument (this is unsafe), just adjust that last line.

2. Keyring daemon

Depending on your OS, you might have access to a keyring which you can store your passwords in. On linux, this might be the gnome keyring daemon. Then this keyring can probably be accessed via CLI/script somehow.
For example, there is gkeyring for use with the gnome keyring daemon.

Can't make SVN store passwords, even though the configuration is set to allow it

Thanks to your comments I found the problem - it's the settings in the servers file (don't store plain passwords). I wonder why there is this redundancy with the [auth] section of the configuration file. The SVN book also does not mention this when talking about storing passwords.

Best tool to code a linux daemon that runs indefinitely?

This is such a common problem that people already wrote several utilities to do just that (in general they are called watchdogs).

You can compare the available options and inspect the sources of the one you like more. Some of them are:

• if you are in Ubuntu, try upstart.
• daemontools
• supervisord (my favorite).

You can run the task periodically using cron, but it is hard to prevent concurrency (it is hard to do it well, dealing with locks, stale locks, etc.).

unix passwd required capabilites

Impossible unless you want to destroy the security of the system.

If the "passwd" utility can do its job as a normal user, then any user could write their own version to change the password of any other user. (That is, take the source code to the utility, modify it to skip asking for the current password, compile, and run.)

I suppose you could create a "password daemon" that runs as root and listens on a socket in order to service password change requests. Why you would want that instead of a set-uid /usr/bin/passwd is beyond me, though; the security implications are identical.

But no matter what you do, changing the password database can only be allowed for some trusted process. Otherwise anybody can change anybody else's password, which kind of defeats the purpose of a multi-user OS.

Looking for a safe, portable password-storage method

You could use a SQLite database. As it's just a file you can use standard file permissions to restrict access. e.g. chmod 600 foo.dbs will restrict access to the file so that only the owner can read/write to it.

Then as others have suggested you store a hashed password in the database and it'll be reasonably secure.

Rumour has it that there's a commercial version of SQLite available that encrypts the entire database file. However, this shouldn't be a substitute for storing hashed passwords, merely an addition to hashing.

edit: Here's the link to the commercial version of sqlite with support for encryption of the entire DB.

---

Related Topics