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