1

Is there some way of having container files / LVM devices transparent dencrypted on the fly without mounting them into the filesystem?

All the encryption solutions I know like LUKS-LVM, gpg containers ect require me to decrypt the device, mount it into the filesystem to access data. I was looking for something like Docker, which gives me an environment to store data in and giving users access to that. However I also want to reduce the risk of data being comprimized. When I have an encrypted image for Docker, I would have to mount it into the filesystem for Docker to access it. Anyone who somehow legally or illegaly gained access to the system at root level would be able to read this mount point and get the data from there. I want to minimize that risk, so that I can access the data on the image/container only through some kind of a server/client system that controlls user access using keys.

Is this somehow possible?

3
  • 1
    I think Linux supports process specific file system mounts. But somebody with root can access anything in your process anyways. Nov 11 '16 at 14:39
  • 1
    You should either go with virtualization (VMs remain isolated unless you compromise the hypervisor) or DRM hardware like Intel SGX enclaves. Nov 11 '16 at 14:42
  • @CodesInChaos yes, but if we had a service this would require extracting keys or data on the fly from ram which could be more difficult than simply browsing a mounted container in the filesystem. Is there a VM system that allows that level of security? Nov 11 '16 at 15:02
1

If you want to ensure that users only have access to their files by providing a key (possibly stored in memory so they don't have to provide it over and over again), then why don't you just use a plain, unencrypted filesystem and encrypt each file individually?

Maybe because this leaks information about number of files, creation and modification dates, file sizes and possibly file names if you don't encrypt them. So you start writing some code around that solution and finally you end up with a solution which stores individual files in a container so that you have control over the file metadata.

And now you've reinvented LUKS, TrueCrypt,VeraCrypt, ...

The one difference between your system and these solutions is that your system supports individual keys for each user while LUKS & Co just use a single key. But you can get almost the same behaviour from LUKS by creating a single container per user. You still have the problem that if someone gets root access to the machine, he can read all the open containers.

However, he can also do that when each file is individually encrypted. You need an interface to your system which takes a user and a filename, decrypts the file on the fly using the users key, which sits in memory, and returns the decrypted file contents. What's to stop root from using this same interface, masquerading as the user?

Basically, LUKS below a standard filesystem provides the interface you'd have to design yourself otherwise. There are only two solutions I can see that would give you more security (but not what you envision):

  1. Use a TPM to protect the user keys. This way they won't be stolen from memory, but a user who has root can still masquerade as another user and decrypt every file by ordering the TPM to decrypt its contents.

  2. Put the encrypted data and an access API on a dedicated machine which only serves your application and is only accessible using the access API. This makes for a much smaller attack surface on your encrypted data. But it also can't protect you from a compromised root account on your app server or the storage server.

So, to sum up: I think you already get what you want out of the box with LUKS. There is no secure line of defense against compromised root.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.