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

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

 



On Thu, Dec 12, 2013 at 3:18 PM, helices <dm-crypt@xxxxxxxxxxxxxxx> 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

_______________________________________________
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