All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schniedermeyer <ms@citd.de>
To: helices <dm-crypt@mdsresource.net>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Can SED/FDE limit access to a particular user?
Date: Thu, 12 Dec 2013 17:51:53 +0100	[thread overview]
Message-ID: <20131212165153.GA14243@citd.de> (raw)
In-Reply-To: <CACNUArDO_jM93cd2zfCcpLGp4Kg71qFQ8Y1iuB6F=ojonKqqSw@mail.gmail.com>

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

  reply	other threads:[~2013-12-12 16:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12 15:18 [dm-crypt] Can SED/FDE limit access to a particular user? helices
2013-12-12 16:51 ` Matthias Schniedermeyer [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131212165153.GA14243@citd.de \
    --to=ms@citd.de \
    --cc=dm-crypt@mdsresource.net \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.