Hi, Matthias!
Yes, a bit of clarification.On Thu, Dec 12, 2013 at 10:51 AM, Matthias Schniedermeyer <ms@xxxxxxx> wrote:
A little more precision in the description would be nice.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?
- 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
