are ecryptfs folders secure from root / local user?

Asked by Dominic Raferd on 2010-06-24

I have a backup server configuration using Ubuntu 10.04LTS, not presently using ecryptfs. Multiple users can make backups to this server (i.e. to their /home folder). Although users cannot see one another's data, the administrator of the server can easily get to see all the data. I want a solution in which the administrator has no way of reading the user's private data, still allowing the user to put the data there (using [rdiff-backup over] ssh, with key-pair authentication) and allowing the user to recover data similarly via ssh.

I am not clear if ecryptfs offers a really secure solution for this, for instance one that could be used for a public backup server, or in any organisation which does not want the techie to see all the corporate secrets!

So I need the user to be able to access their private folder via ssh in an automated way (using their key-pair), both for read and write, but anyone without the private key - including the administrator and any local user of the server - must be unable to read the underlying data in this private folder in any circumstances.

Can ecryptfs offer this? Thanks for your reply!

Question information

Language:
English Edit question
Status:
Solved
For:
eCryptfs Edit question
Assignee:
No assignee Edit question
Solved by:
Ted_Smith
Solved:
2010-09-03
Last query:
2010-09-03
Last reply:
2010-06-29
Serge Hallyn (serge-hallyn) said : #1

You seem to be talking about two different things. First you talk about
users backing up their private data to a shared backup server. Ecryptfs
does support that. You can provide them with a program which unmounts
the ecryptfs mount (in a private namespace) so that it cannot see the
decrypted data, and then rsyncs $HOME/.Private to the backup server.

Then you talk about users ssh'ing in. So long as you only mean using
ssh to provide a secure way to rsync their encrypted data back and
forth, that is fine and doable.

But if you want users to be able to log into the backup server and see
their decrypted data there, while guaranteeing that admins on the backup
server cannot see the decrypted data, there is no way to achieve this
(without IMA, EVM, SELinux, and remote attestation), and it is not an
ecryptfs shortcoming. If nothing else, consider that while the user is
editing $HOME/my-secret-file, the admin can read the contents of the
file being edited through /proc/<pid>/fd/, where <pid> is the process
id of the editor.

Thanks for your swift reply. I think the second part answers the question I had. I was envisaging remote backup and recovery of decrypted data (which would however be held in encrypted form on the remote server) and I understand now that this cannot be done securely.

The first part of your answer got me thinking about backup of the encrypted data as an alternative approach. How efficient is rsync'ing ecryptfs encrypted data? If the source data is very large and changing very little (i.e. a long standing large backup data set), and this data is held in an ecryptfs mount, and rsync'd daily to an offsite insecure backup server, how much more traffic does this generate than a straightforward rsync of the unencrypted data? I appreciate there can be no precise answer but is it say +10% more traffic, or more like +100% or +1000%?

Even so, it is not a very practical backup solution because recovery of any small piece of the data from the remote server (e.g. 1 file) would I presume require recovery of the entire encrypted data set (which might contain 10000 files).

So a more practical approach would seem to be each user having their own dedicated remote VM which is fully encrypted (as offered in Ubuntu 10.04, I presume using ecryptfs) - maybe this could be secure, i.e. the remote administrator (who provides the VMs on the remote server) cannot get access to the VM or the encrypted data on it?

Serge Hallyn (serge-hallyn) said : #3

> Even so, it is not a very practical backup solution because recovery of
> any small piece of the data from the remote server (e.g. 1 file) would I
> presume require recovery of the entire encrypted data set (which might
> contain 10000 files).

No, each file is separately encrypted, so you can restore a single file.

Ah, I see - yes, if you are using filename encryption you have a problem
of figuring out which file to restore. I would recommend simply not using
filename encryption. Is that reasonable for your users?

Best Ted_Smith (tedsmith28) said : #4

Yes, each file has it's own FEK (File Encryption Key), so you could easily restore one, a dozen or a hundred files, providing you have the FEKEK (File Encryption Key, Encryption Key), which is basically your mount passphrase.

If you are sending eCryptfs encrypted files anywhere, without the mount passphrase, and the data is not being decrypted elsewhere, then no body will be able to read it. Not the system admin, hackers, or anybody else.

Thanks Ted_Smith, that solved my question.