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

helices dm-crypt at mdsresource.net
Thu Dec 12 18:13:57 CET 2013


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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20131212/1c208c88/attachment.html>


More information about the dm-crypt mailing list