* [dm-crypt] Can SED/FDE limit access to a particular user? @ 2013-12-12 15:18 helices 2013-12-12 16:51 ` Matthias Schniedermeyer 2013-12-12 20:14 ` Claudio Moretti 0 siblings, 2 replies; 6+ messages in thread From: helices @ 2013-12-12 15:18 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 1535 bytes --] We have to protect sensitive files and keep them available for use by a particular user for 7+ years We prefer self encrypted disk (SED), but, it's being too difficult to get a straight answer regarding do-ability of our application. We are currently using LUKS filesystems on several servers - so we know how good this is. We do not, however, know whether or not we can do what we want with it. We understand how full disk encryption (FDE) normally works: once the drive is decrypted (via key/password, etc.) then the whole drive is visible to whomever has system access We do NOT want that. Ideally, the drive will be unreadable to everybody. During a brief period of time when a new file is to be written to the drive and also a brief period of time when a particular file is to be read from disk, a specific user would "unlock" the drive for this specific task, after which the whole drive will be unreadable to everybody. We would consider other scnearios; but, it is essential that all of the contents of this disk are unreadable to everybody, except one particular user. Furthermore, as a file server application serving enterprise critical files, redundancy is also a high priority. Currently, we run several SANs with RAID 6 and prefer similar redundancy for this application. Almost all of our servers are Linux based and we prefer the same here. We do a high volume of PGP/GPG file encryption for file transfer; but, we prefer FDE for static files How can we accomplish this? Please, advise. Thank you. ~ helices [-- Attachment #2: Type: text/html, Size: 1843 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Can SED/FDE limit access to a particular user? 2013-12-12 15:18 [dm-crypt] Can SED/FDE limit access to a particular user? helices @ 2013-12-12 16:51 ` Matthias Schniedermeyer 2013-12-12 17:13 ` helices 2013-12-12 20:14 ` Claudio Moretti 1 sibling, 1 reply; 6+ messages in thread From: Matthias Schniedermeyer @ 2013-12-12 16:51 UTC (permalink / raw) To: helices; +Cc: dm-crypt On 12.12.2013 09:18, helices wrote: > We have to protect sensitive files and keep them available for use by a > particular user for 7+ years > > We prefer self encrypted disk (SED), but, it's being too difficult to get a > straight answer regarding do-ability of our application. We are currently > using LUKS filesystems on several servers - so we know how good this is. We > do not, however, know whether or not we can do what we want with it. > > We understand how full disk encryption (FDE) normally works: once the drive > is decrypted (via key/password, etc.) then the whole drive is visible to > whomever has system access > > We do NOT want that. > > Ideally, the drive will be unreadable to everybody. During a brief period > of time when a new file is to be written to the drive and also a brief > period of time when a particular file is to be read from disk, a specific > user would "unlock" the drive for this specific task, after which the whole > drive will be unreadable to everybody. > > We would consider other scnearios; but, it is essential that all of the > contents of this disk are unreadable to everybody, except one particular > user. > > Furthermore, as a file server application serving enterprise critical > files, redundancy is also a high priority. Currently, we run several SANs > with RAID 6 and prefer similar redundancy for this application. > > Almost all of our servers are Linux based and we prefer the same here. > > We do a high volume of PGP/GPG file encryption for file transfer; but, we > prefer FDE for static files > > How can we accomplish this? A little more precision in the description would be nice. - You don't trust root? (Which means you are pretty screwed, unless you are already using SELinux or somesuch) - It should be a client/server "thing"? Those 2 are quite potent mutual exclusions. - Backup to a remote Server Or would a USB-HDD or somesuch be "enough"? With a dedicated computer that can only be controller by the user it wouldn't be that hard. ecryptfs (no personal experience) would make it easy to backup, just rsync the encrypted files. A little autofs "magic" helps with automating the setup/teardown. I personally mount most of my encrypted devices by autofs, altough i had to patch [u]mount for the setup/teardown of dm-crypt as i'm using the "standard" direct(?)-mapping with the ghosting-option (To have 'tab'able direcories), there are other mapping-types that should support it without such clutches. Depending on how the mounting of ecryptfs works (again, no personal experience) a little integration with gpg-agent or somesuch should make it possible to for e.g. load a key or an hour or so and then have it automountable in that timeframe. And autofs does that umount automatically if there are no open files and the timeout runs out. -- Matthias ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Can SED/FDE limit access to a particular user? 2013-12-12 16:51 ` Matthias Schniedermeyer @ 2013-12-12 17:13 ` helices 2013-12-12 18:07 ` Matthias Schniedermeyer 2013-12-12 20:34 ` Arno Wagner 0 siblings, 2 replies; 6+ messages in thread From: helices @ 2013-12-12 17:13 UTC (permalink / raw) To: Matthias Schniedermeyer; +Cc: dm-crypt [-- Attachment #1: Type: text/plain, Size: 4023 bytes --] 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. 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. FDE protects data if the disk is stolen. We want to protect the data on the live system as well. Does this make sense to you? Please, advise. Thank you. ~ helices On Thu, Dec 12, 2013 at 10:51 AM, Matthias Schniedermeyer <ms@citd.de>wrote: > On 12.12.2013 09:18, helices wrote: > > We have to protect sensitive files and keep them available for use by a > > particular user for 7+ years > > > > We prefer self encrypted disk (SED), but, it's being too difficult to > get a > > straight answer regarding do-ability of our application. We are currently > > using LUKS filesystems on several servers - so we know how good this is. > We > > do not, however, know whether or not we can do what we want with it. > > > > We understand how full disk encryption (FDE) normally works: once the > drive > > is decrypted (via key/password, etc.) then the whole drive is visible to > > whomever has system access > > > > We do NOT want that. > > > > Ideally, the drive will be unreadable to everybody. During a brief period > > of time when a new file is to be written to the drive and also a brief > > period of time when a particular file is to be read from disk, a specific > > user would "unlock" the drive for this specific task, after which the > whole > > drive will be unreadable to everybody. > > > > We would consider other scnearios; but, it is essential that all of the > > contents of this disk are unreadable to everybody, except one particular > > user. > > > > Furthermore, as a file server application serving enterprise critical > > files, redundancy is also a high priority. Currently, we run several SANs > > with RAID 6 and prefer similar redundancy for this application. > > > > Almost all of our servers are Linux based and we prefer the same here. > > > > We do a high volume of PGP/GPG file encryption for file transfer; but, we > > prefer FDE for static files > > > > How can we accomplish this? > > A little more precision in the description would be nice. > > - You don't trust root? (Which means you are pretty screwed, unless you > are already using SELinux or somesuch) > - It should be a client/server "thing"? > Those 2 are quite potent mutual exclusions. > > - Backup to a remote Server > Or would a USB-HDD or somesuch be "enough"? > > > With a dedicated computer that can only be controller by the user it > wouldn't be that hard. > > ecryptfs (no personal experience) would make it easy to backup, just > rsync the encrypted files. > > A little autofs "magic" helps with automating the setup/teardown. I > personally mount most of my encrypted devices by autofs, altough i had > to patch [u]mount for the setup/teardown of dm-crypt as i'm using the > "standard" direct(?)-mapping with the ghosting-option (To have 'tab'able > direcories), there are other mapping-types that should support it > without such clutches. > > Depending on how the mounting of ecryptfs works (again, no personal > experience) a little integration with gpg-agent or somesuch should make > it possible to for e.g. load a key or an hour or so and then have it > automountable in that timeframe. And autofs does that umount > automatically if there are no open files and the timeout runs out. > > > > -- > > Matthias > [-- Attachment #2: Type: text/html, Size: 5213 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Can SED/FDE limit access to a particular user? 2013-12-12 17:13 ` helices @ 2013-12-12 18:07 ` Matthias Schniedermeyer 2013-12-12 20:34 ` Arno Wagner 1 sibling, 0 replies; 6+ messages in thread From: Matthias Schniedermeyer @ 2013-12-12 18:07 UTC (permalink / raw) To: helices; +Cc: dm-crypt On 12.12.2013 11:13, 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. That can be done with basic filesystem permissions. - mount it - chown user /mntpoint - chmod 700 /mntpoint After that only the user with that specific uid (and root) can access the data below that mountpoint, nobody else. > 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. LUKS is not a fileystems. It's a "bit-bucket" with a defined header that provides it's "payload" as a transparently de-/encrypted block device. Ontop of which you can put a filesystem. After a LUKS device has been opened the resulting dm-crypt device is like any other block-device, there is no more or less security than any other block-device. Same goes for the (technically optional) filesystem. You have all (un)security that the used file filesystems provides, regardless of the underlying block-device beeing encrypted or not. IOW the filesystem doesn't "know" that it's underlying block-device is encrypted and the underlying block-device couldn't care less about was is put inside it, it's just a bit-bucket. > FDE protects data if the disk is stolen. Exactly. > We want to protect the data on the live system as well. > > Does this make sense to you? Some sense yes. But "online" security is it's own research field with practically endless complexity and compromise, unlike "offline" security which is relativly simpel and simple to understand. For "online" security you have to create a threat model that you want to defend against and model your solution accordingly and see where you may have to make compromises so the solution is still practical. One of the first questions in "online" security: "Can you trust root" is quite essential in what you can/can't/have to do. If you trust root and "standard" permissions, the chown/chmod maybe all you need. You would need to be root to circumvent basic filesystem permissions, or you would need the password/key and the device to mount it on another computer where you could circumvent the filesystem permissions. > On Thu, Dec 12, 2013 at 10:51 AM, Matthias Schniedermeyer <ms@citd.de>wrote: > > > On 12.12.2013 09:18, helices wrote: > > > We have to protect sensitive files and keep them available for use by a > > > particular user for 7+ years > > > > > > We prefer self encrypted disk (SED), but, it's being too difficult to > > get a > > > straight answer regarding do-ability of our application. We are currently > > > using LUKS filesystems on several servers - so we know how good this is. > > We > > > do not, however, know whether or not we can do what we want with it. > > > > > > We understand how full disk encryption (FDE) normally works: once the > > drive > > > is decrypted (via key/password, etc.) then the whole drive is visible to > > > whomever has system access > > > > > > We do NOT want that. > > > > > > Ideally, the drive will be unreadable to everybody. During a brief period > > > of time when a new file is to be written to the drive and also a brief > > > period of time when a particular file is to be read from disk, a specific > > > user would "unlock" the drive for this specific task, after which the > > whole > > > drive will be unreadable to everybody. > > > > > > We would consider other scnearios; but, it is essential that all of the > > > contents of this disk are unreadable to everybody, except one particular > > > user. > > > > > > Furthermore, as a file server application serving enterprise critical > > > files, redundancy is also a high priority. Currently, we run several SANs > > > with RAID 6 and prefer similar redundancy for this application. > > > > > > Almost all of our servers are Linux based and we prefer the same here. > > > > > > We do a high volume of PGP/GPG file encryption for file transfer; but, we > > > prefer FDE for static files > > > > > > How can we accomplish this? > > > > A little more precision in the description would be nice. > > > > - You don't trust root? (Which means you are pretty screwed, unless you > > are already using SELinux or somesuch) > > - It should be a client/server "thing"? > > Those 2 are quite potent mutual exclusions. > > > > - Backup to a remote Server > > Or would a USB-HDD or somesuch be "enough"? > > > > > > With a dedicated computer that can only be controller by the user it > > wouldn't be that hard. > > > > ecryptfs (no personal experience) would make it easy to backup, just > > rsync the encrypted files. > > > > A little autofs "magic" helps with automating the setup/teardown. I > > personally mount most of my encrypted devices by autofs, altough i had > > to patch [u]mount for the setup/teardown of dm-crypt as i'm using the > > "standard" direct(?)-mapping with the ghosting-option (To have 'tab'able > > direcories), there are other mapping-types that should support it > > without such clutches. > > > > Depending on how the mounting of ecryptfs works (again, no personal > > experience) a little integration with gpg-agent or somesuch should make > > it possible to for e.g. load a key or an hour or so and then have it > > automountable in that timeframe. And autofs does that umount > > automatically if there are no open files and the timeout runs out. > > > > > > > > -- > > > > Matthias > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Matthias ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Can SED/FDE limit access to a particular user? 2013-12-12 17:13 ` helices 2013-12-12 18:07 ` Matthias Schniedermeyer @ 2013-12-12 20:34 ` Arno Wagner 1 sibling, 0 replies; 6+ messages in thread From: Arno Wagner @ 2013-12-12 20:34 UTC (permalink / raw) To: dm-crypt 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@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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dm-crypt] Can SED/FDE limit access to a particular user? 2013-12-12 15:18 [dm-crypt] Can SED/FDE limit access to a particular user? helices 2013-12-12 16:51 ` Matthias Schniedermeyer @ 2013-12-12 20:14 ` Claudio Moretti 1 sibling, 0 replies; 6+ messages in thread From: Claudio Moretti @ 2013-12-12 20:14 UTC (permalink / raw) To: helices; +Cc: dm-crypt@saout.de [-- Attachment #1: Type: text/plain, Size: 2867 bytes --] On Thu, Dec 12, 2013 at 3:18 PM, helices <dm-crypt@mdsresource.net> wrote: > We understand how full disk encryption (FDE) normally works: once the > drive is decrypted (via key/password, etc.) then the whole drive is visible > to whomever has system access > That is not exact; as Matthias said, filesystem permissions allow you to limit access to the FS, making sure that nobody except the user who has the FS permissions (and root, of course) can access such files. That is not, as far as I'm aware, the purpose of LUKS which is (using Matthias's words again) a "bit-bucket" with a defined header that provides it's "payload" as a > transparently de-/encrypted block device. Ontop of which you can put a > filesystem. > That is, of course, if by "system access" you mean "access to the system". If you're worried about people with root access, than it's another matter entirely. However, you could (and FYI I haven't tested it, it's just a thought, but I believe it's a valid one) build a system with an unencrypted system partition and an encrypted data partition (as happens when having / unenecrypted and /home encrypted) In this system you could install your preferred data transfer client, let's say rsync (the only one I can think at the moment with the minimum requirements I'm thinking about). You can configure it to[1]: - authenticate users before transferring - chroot the session - *execute commands before and after the transfer* This is done using the > *pre-xfer exec*, *post-xfer exec* > You may specify a command to be run before and/or after the transfer. If > the *pre-xfer exec* command fails, the transfer is aborted before it > begins. directives. With those, you could unlock the encrypted partition, mount it (use /dev/disk/by-uuid to be sure you're not mounting the wrong one), transfer, unmount it and lock it again, and this happens in what I believe is the shortest time possible, and it seems to me it aligns with the requirement you were mentioning: > Ideally, the drive will be unreadable to everybody. During a brief period > of time when a new file is to be written to the drive and also a brief > period of time when a particular file is to be read from disk, a specific > user would "unlock" the drive for this specific task, after which the whole > drive will be unreadable to everybody. > You can run the daemon under a specific uig/gid and, if you need to, you can enable it to be "write only". This should not affect your RAID6 configuration, as we're above system level (well above LUKS level) and the only thing you'll have to worry about is the cipher you chose when you first set up the encrypted drive. Again, this is only a thought, but on [electronic] paper it seems te simplest solution. Feel free to let me know if I misunderstood something. Cheers, Claudio [1] http://linux.die.net/man/5/rsyncd.conf [-- Attachment #2: Type: text/html, Size: 4178 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-12 20:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-12-12 15:18 [dm-crypt] Can SED/FDE limit access to a particular user? helices 2013-12-12 16:51 ` Matthias Schniedermeyer 2013-12-12 17:13 ` helices 2013-12-12 18:07 ` Matthias Schniedermeyer 2013-12-12 20:34 ` Arno Wagner 2013-12-12 20:14 ` Claudio Moretti
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.