[dm-crypt] Can SED/FDE limit access to a particular user?
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:
> 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
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
3. Create a directoy within the first that serves as
4. Mount whatever filesystem is in the LUKS container
on the mount point from 3.
5. Determine somehow when to remove access again.
- 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
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
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