"holding open" encrypted home with local ssh

Question

I have a couple of machines that I use for purely automated stuff, with home directories encrypted using ecryptfs. So even if the machine is powered on, those directories aren't decrypted unless that user logs in (desired behavior). Now, I'd like to be able to run a server using one of these users (data stored therein), and I don't mind logging it in once when the service is started. However, I don't want to leave an open SSH session from another machine to the automated one.

My current strategy is a script that runs a localhost SSH session inside a screen process, which then detaches after logging in. This keeps the user "logged in to herself" as long as that screen process is running. I run this script from outside using SSH, and then drop the remote SSH session, leaving the localhost screen-ed SSH session running, keeping the ecryptfs directory mounted.

What are the security risks of this approach, if any?

Answer 1

If someone gains access to your system by software means while the encrypted filesystem is mounted, they gain access to the filesystem.

If someone gains access to your system by software means while the encrypted filesystem is not mounted, they may still gain access to the filesystem: it depends when you detect the intrusion. If they manage to gain root (and not just access as some other confined system daemon), then they can plant malware that will record the filesystem's password and decryption key the next time you enter the decryption password.

If someone gains access to your system by hardware means while the encrypted filesystem is mounted, they may gain access to the filesystem. For example, they can perform a warm RAM extraction and dump the keys from memory.

So by keeping the directories unencrypted you are increasing the risk window. However, the only way to reduce that risk is to stop operating the server — the server process needs to access its data anyway.

Keeping a Screen process running, as opposed to, say, turning off automatic unmounting, only has a security impact if there is a vulnerability in Screen. Screen is a mature, fairly stable program, so the likelihood that an as yet unknown vulnerability will be discovered in it is rather low. Screen's security relies on file permissions (the ownership of the socket directory), so in any case anything that can affect it is highly likely to be able to affect the service-providing daemon as well.

In practical terms, this approach does not increase the risk beyond that inherent in running the daemon in the first place.