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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
