On Thu, Dec 12, 2013 at 3:18 PM, helices <dm-crypt at mdsresource.net> wrote:
> 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
>That is not exact; as Matthias said, filesystem permissions allow you to
limit access to the FS, making sure that nobody except the user who has the
FS permissions (and root, of course) can access such files.
That is not, as far as I'm aware, the purpose of LUKS which is (using
Matthias's words again)
a "bit-bucket" with a defined header that provides it's "payload" as a
> transparently de-/encrypted block device. Ontop of which you can put a
> filesystem.
>
That is, of course, if by "system access" you mean "access to the system".
If you're worried about people with root access, than it's another matter
entirely.
However, you could (and FYI I haven't tested it, it's just a thought, but I
believe it's a valid one) build a system with an unencrypted system
partition and an encrypted data partition (as happens when having /
unenecrypted and /home encrypted)
In this system you could install your preferred data transfer client, let's
say rsync (the only one I can think at the moment with the minimum
requirements I'm thinking about).
You can configure it to[1]:
- authenticate users before transferring
- chroot the session
-
*execute commands before and after the transfer*
This is done using the
> *pre-xfer exec*, *post-xfer exec*
> You may specify a command to be run before and/or after the transfer. If
> the *pre-xfer exec* command fails, the transfer is aborted before it
> begins.
directives.
With those, you could unlock the encrypted partition, mount it (use
/dev/disk/by-uuid to be sure you're not mounting the wrong one), transfer,
unmount it and lock it again, and this happens in what I believe is the
shortest time possible, and it seems to me it aligns with the requirement
you were mentioning:
> 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.
>You can run the daemon under a specific uig/gid and, if you need to, you
can enable it to be "write only".
This should not affect your RAID6 configuration, as we're above system
level (well above LUKS level) and the only thing you'll have to worry about
is the cipher you chose when you first set up the encrypted drive.
Again, this is only a thought, but on [electronic] paper it seems te
simplest solution.
Feel free to let me know if I misunderstood something.
Cheers,
Claudio
[1] http://linux.die.net/man/5/rsyncd.conf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20131212/900e8320/attachment.html>