unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Input needed regarding disk encryption/decryption
@ 2016-10-06  2:56 dian_cecht
  2016-10-06  5:04 ` John Darrington
  2016-10-06 13:01 ` Christopher Allan Webber
  0 siblings, 2 replies; 5+ messages in thread
From: dian_cecht @ 2016-10-06  2:56 UTC (permalink / raw)
  To: guix-devel

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-10-06 18:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-06  2:56 Input needed regarding disk encryption/decryption dian_cecht
2016-10-06  5:04 ` John Darrington
2016-10-06  8:47   ` dian_cecht
2016-10-06 18:51   ` Hartmut Goebel
2016-10-06 13:01 ` Christopher Allan Webber

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).