Re: Can SED/FDE limit access to a particular user?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux