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
next prev parent 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.