How secure is a Python Pyro daemon for storing a password?

Question

I am using the Pyro package to create a daemon which will, upon startup, prompt for a password, and then the daemon will store that password as long as it is running. Other scripts will then make a Pyro connection to this daemon and execute methods from the daemon, none of which reveal or have access to the password:

my_daemon.py:

import getpass
import Pyro.core

password = getpass.getpass()

class TestDaemon(Pyro.core.ObjBase):
   def __init__(self):
      Pyro.core.ObjBase.__init__(self)
   def do_some_stuff(self):
      return "I am a method which would do some stuff, utilizing password \"{0}\" which is only accessible from this daemon.".format(password)

Pyro.core.initServer()
daemon=Pyro.core.Daemon()
uri=daemon.connect(TestDaemon(), "TestDaemon")
daemon.requestLoop()

driver.py:

import Pyro.core
my_daemon = Pyro.core.getProxyForURI("PYROLOC://localhost:7766/TestDaemon")
print my_daemon.do_some_stuff()
# note: the password variable in the daemon is inaccessible from here.

I would like advice on how secure this is, and what steps I can take to increase security. I know, for example, that this is not 100% fool proof --- if someone were able to dump the memory, the password would probably be accessible that way. That's an unfortunate one I'm willing to live with. What else?

The "storing-password-in-memory-via-daemon" pattern is not something I can deviate from. This approach was decided on by the team as a whole (as opposed to putting the password in a root read-only text file for example). So it's less a matter of, "what alternatives do I have," and more a matter of, "what tools can I use to accomplish this particular task with the simplest and easiest to maintain code without sacrificing too much security?"

Answer 1

I'm not familiar with Pyro specifically, but this pattern is similar to a lot of other common setups.

As you've mentioned, the daemon is storing the password in memory, so any sort of memory dump can retrieve it.

If a user has local access to the machine, they may be able to attack the initial password entry. Keyloggers are the most obvious tool here; in non-getpass scenarios, you could also leak it through things like reading bash history (if it was in the command-line) or process lists (if it was in the environment).

An attacker may be able to take advantage of flaws in the daemon to write a program that connects to it and gets it to return the password.

Sometimes it doesn't even matter if they have access to the password, as long as they are authenticated. They may be able to trick your application (either through direct connection to the daemon, or a more remote attack via SQL injection-like attacks) to execute attack code with the daemon's privileges.

The "storing-password-in-memory-via-daemon" pattern is not something I can deviate from. This approach was decided on by the team as a whole (as opposed to putting the password in a root read-only text file for example). So it's less a matter of, "what alternatives do I have," and more a matter of, "what tools can I use to accomplish this particular task with the simplest and easiest to maintain code without sacrificing too much security?"

This seems like a reasonable implementation of your chosen pattern.

Answer 2

As mentioned, this is a fairly common pattern. Implementations of this patterns usually is called key-agents (e.g. ssh agent, gpg agent). I suggest looking at their design to get some ideas about how to implement yours. Better yet, if you can, switch to assymmetric auth/crypto instead of password and use preexisting agents instead of writing your own agent. While creating a basic, working agent is not too terribly difficult, creating a secure one involves taking a lot of extra care (e.g. preventing the keys from being written to swap, hibernation/suspend, restricting access to the agent's socket).