[dm-crypt] Can SED/FDE limit access to a particular user?

Arno Wagner arno at wagner.name
Thu Dec 12 21:34:10 CET 2013


On Thu, Dec 12, 2013 at 18:13:57 CET, helices wrote:
> Hi, Matthias!
> 
> Yes, a bit of clarification.
> 
> It is not a matter of not trusting root.
> 
> Rather, the "read" and "write" processes are sub-processes of a more
> extensive process and will run as a non-privileged user - not root.
> 
> Therefore, it is simpler - read, easier for the PCI-DSS auditor to
> comprehend its security - if only this non-privileged user can read and
> write on this filesystem.

Ok, going through an audit like this, you want everything as 
simple as possible, quite understandable.
 
> I see statements like this: "LUKS allows multiple user keys to decrypt a
> master key which is used for the bulk encryption of the partition" here:
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html
> 
> This implies that a non-privileged user can have sole access to a LUKS
> filesystem. "Implicit" must be made explicit.

No. It means that anybody that has root permissions can supply a 
passphrase. The "users" here refers to people, not to OS roles.
In most situations a user has to be logged in as root to 
use cryptestup directly. Indirect use can of course be 
via a custom demon or suid-binary.

> FDE protects data if the disk is stolen.
> 
> We want to protect the data on the live system as well.

That is not a job for encryption. That is a job for normal OS
access control mechanisms. For example, an NFS daemon does this
or filesystem permission do. Encryption can only be added as
an additional mechanism, but it is all-or-nothing. 

You could, for example, have a daemon that a user (OS role)
supplies its (person) passphrase to and the daemon does the 
following:

1. Open LUKS container withe the passphrase.
   Wipe passprase from demon memory here already.
2. Create a directory that only this user (OS role) can 
   get into.
3. Create a directoy within the first that serves as 
   mount point.
4. Mount whatever filesystem is in the LUKS container
   on the mount point from 3.
5. Determine somehow when to remove access again.
   Options:
   - fixed time after opening
   - fixed idle time (the automounter does this, for example).
   - user (person) driven
6. When time to close is reached
   I. Kill all processes that still access the directory
     (otherwise you cannot umount)
   II. Umount directory
   III. close LUKS container.
   
For this to be secure, you must make sure that the passphrase
does not stay in memory somewhere or, worse, goes into swap.
Proper memory locking (against swapping) and wiping is critical. 
This may mean you have to do a C/C++ implementation for this.
You should also use SELinux to lock it down further.

You may also need an independent security evaluation for daemon
or program as input for the auditor. I have not done one for 
PCI-DSS so far, so I do not know what the auditor may require 
here. 

This is however completely out of scope for cryptsetup, which 
does only protect a blob (file, partition) from access by root. 
Any filesystem within the LUKS container is not the business of 
cryptsetup. 

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare


More information about the dm-crypt mailing list