Input needed regarding disk encryption/decryption

Input needed regarding disk encryption/decryption

[dian_cecht]

Hello,

     So apparently I've accidentilly volunteered to try and implement whole disk
encryption for GuixSD, and for the last few days I've been pondering what all
I'd need to handle for this. While the obvious low-hanging fruit is to simply
support mounting LUKS devices (or anything under /dev/mapper), if I'm going
to do this I'd rather try to handle as many cases as I could, or at least avoid
doing something that would make future additions to the distro painful to
implement. So I've been trying to come up with a list of the possible
configurations and how they can be implemented, so at least I have a rough idea
on what is actually needed. So far, this is what I'm thinking needs to be
supported (or some combination of each of these):

a) Encrypting /home(/$USER)
b) Encrypting /
c) Encrypting /boot
d) Encrypting swap with a fixed passphrase
e) Encrypting swap with a random passphrase
f) Encrypting /$RANDOM_DIRECTORY

     I think A is usually handled with eCryptFS and PAM so that the user's home
directory isn't mounted until the user logs in, and is thus outside of the scope
of what I'm trying to do. B is the big issue for me (along with RAID support and
LVM, but I'm reasonably sure I can replace LVM with quotas without any loss of
functionality and probably an increase in flexibility) and can usually be
handled fairly easily with an initramfs. However, the inability of the install
image to mount (or configure these devices for mounting) seems to be a fairly
serious stumbling block. C is supported by GRUB2 according to 
https://wiki.archlinux.org/index.php/Grub#Boot_partition
so as long as our version of GRUB has built-in support for this, I think that
shouldn't be too hard to handle. D should be reasonably easy to handle as soon
as we can decide whether it would be better to decrypt everything in the
initramfs or leave some of it to the system proper to handle. E is likely best
handled by the system proper and should be reasonably easy to handle once
a framework for handling decrypting and encrypting filesystems is implemented.
The same applies to F, for that matter.

     I am also pondering how to handle RAID and LVM at this time since all of
this is all fairly closely related, though I'm not going to make any claims of
responsibility for implementing anything other than disk encryption, and even
that isn't promised.

     However, I'm wanting feedback from others on this list (and if someone
wants to crosspost this to the help-guix list for a little more visability, feel
free) on any possible scenerios need to be handled that I havn't mentioned here.

Re: Input needed regarding disk encryption/decryption

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]

I understood something different by "while disk encryption".  I thought it meant
encrypting the whole disk (partition table and all) not just the partitions on it.

J'

On Wed, Oct 05, 2016 at 07:56:23PM -0700, dian_cecht@zoho.com wrote:
     Hello,
     
          So apparently I've accidentilly volunteered to try and implement whole disk
     encryption for GuixSD, and for the last few days I've been pondering what all
     I'd need to handle for this. While the obvious low-hanging fruit is to simply
     support mounting LUKS devices (or anything under /dev/mapper), if I'm going
     to do this I'd rather try to handle as many cases as I could, or at least avoid
     doing something that would make future additions to the distro painful to
     implement. So I've been trying to come up with a list of the possible
     configurations and how they can be implemented, so at least I have a rough idea
     on what is actually needed. So far, this is what I'm thinking needs to be
     supported (or some combination of each of these):
     
     a) Encrypting /home(/$USER)
     b) Encrypting /
     c) Encrypting /boot
     d) Encrypting swap with a fixed passphrase
     e) Encrypting swap with a random passphrase
     f) Encrypting /$RANDOM_DIRECTORY
     
          I think A is usually handled with eCryptFS and PAM so that the user's home
     directory isn't mounted until the user logs in, and is thus outside of the scope
     of what I'm trying to do. B is the big issue for me (along with RAID support and
     LVM, but I'm reasonably sure I can replace LVM with quotas without any loss of
     functionality and probably an increase in flexibility) and can usually be
     handled fairly easily with an initramfs. However, the inability of the install
     image to mount (or configure these devices for mounting) seems to be a fairly
     serious stumbling block. C is supported by GRUB2 according to 
     https://wiki.archlinux.org/index.php/Grub#Boot_partition
     so as long as our version of GRUB has built-in support for this, I think that
     shouldn't be too hard to handle. D should be reasonably easy to handle as soon
     as we can decide whether it would be better to decrypt everything in the
     initramfs or leave some of it to the system proper to handle. E is likely best
     handled by the system proper and should be reasonably easy to handle once
     a framework for handling decrypting and encrypting filesystems is implemented.
     The same applies to F, for that matter.
     
          I am also pondering how to handle RAID and LVM at this time since all of
     this is all fairly closely related, though I'm not going to make any claims of
     responsibility for implementing anything other than disk encryption, and even
     that isn't promised.
     
          However, I'm wanting feedback from others on this list (and if someone
     wants to crosspost this to the help-guix list for a little more visability, feel
     free) on any possible scenerios need to be handled that I havn't mentioned here.
     

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Input needed regarding disk encryption/decryption

[dian_cecht]

On Thu, Oct 06, 2016 at 07:04:14AM +0200, John Darrington wrote:
> I understood something different by "while disk encryption".  I thought it meant
> encrypting the whole disk (partition table and all) not just the partitions on it.

I am looking at whole disk encryption as well as other options.

Re: Input needed regarding disk encryption/decryption

[Hartmut Goebel]

[-- Attachment #1.1: Type: text/plain, Size: 765 bytes --]

Am 06.10.2016 um 07:04 schrieb John Darrington:
> I understood something different by "while disk encryption".  I thought it meant
> encrypting the whole disk (partition table and all) not just the partitions on it.

I doubt this is possible without BIOS/UEFI support. And I'm not aware of
any such solution for Linux.

-- 
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Development

Goebel Consult, Landshut
http://www.goebel-consult.de

Blog:
http://www.goebel-consult.de/blog/vorratsdatenspeicherung-jetzt-verfassungsbeschwerde-unterschreiben

Kolumne: http://www.cissp-gefluester.de/2010-07-passwoerter-lieben-lernen


[-- Attachment #1.2: Type: text/html, Size: 1928 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2430 bytes --]

Re: Input needed regarding disk encryption/decryption

[Christopher Allan Webber]

dian_cecht@zoho.com writes:

>      I am also pondering how to handle RAID and LVM at this time since all of
> this is all fairly closely related, though I'm not going to make any claims of
> responsibility for implementing anything other than disk encryption, and even
> that isn't promised.
>
>      However, I'm wanting feedback from others on this list (and if someone
> wants to crosspost this to the help-guix list for a little more visability, feel
> free) on any possible scenerios need to be handled that I havn't mentioned here.

I'm not sure enough to comment on RAID, but having an encrypted LVM
option is basically what Debian ships with out of the box, and that
seems good-enough to me.