From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Darrington Subject: Re: Input needed regarding disk encryption/decryption Date: Thu, 6 Oct 2016 07:04:14 +0200 Message-ID: <20161006050414.GA12837@jocasta.intra> References: <20161006025623.GA28797@khaalida> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bs0qz-0006VC-By for guix-devel@gnu.org; Thu, 06 Oct 2016 01:04:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bs0qv-0003kp-2O for guix-devel@gnu.org; Thu, 06 Oct 2016 01:04:20 -0400 Received: from de.cellform.com ([88.217.224.109]:57162 helo=jocasta.intra) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bs0qu-0003kZ-LG for guix-devel@gnu.org; Thu, 06 Oct 2016 01:04:16 -0400 Received: from jocasta.intra (localhost [127.0.0.1]) by jocasta.intra (8.14.4/8.14.4/Debian-8) with ESMTP id u9654FN7012894 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 6 Oct 2016 07:04:15 +0200 Received: (from john@localhost) by jocasta.intra (8.14.4/8.14.4/Submit) id u9654E6p012893 for guix-devel@gnu.org; Thu, 6 Oct 2016 07:04:14 +0200 Content-Disposition: inline In-Reply-To: <20161006025623.GA28797@khaalida> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, =20 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 w= hat 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 le= ast 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 r= ough 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): =20 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 =20 I think A is usually handled with eCryptFS and PAM so that the us= er'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 s= upport 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=20 https://wiki.archlinux.org/index.php/Grub#Boot_partition so as long as our version of GRUB has built-in support for this, I thi= nk 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 t= he initramfs or leave some of it to the system proper to handle. E is lik= ely best handled by the system proper and should be reasonably easy to handle o= nce a framework for handling decrypting and encrypting filesystems is impl= emented. The same applies to F, for that matter. =20 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 c= laims of responsibility for implementing anything other than disk encryption, a= nd even that isn't promised. =20 However, I'm wanting feedback from others on this list (and if so= meone wants to crosspost this to the help-guix list for a little more visabi= lity, feel free) on any possible scenerios need to be handled that I havn't menti= oned here. =20 --=20 Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3=20 fingerprint =3D 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlf1204ACgkQimdxnC3oJ7P9VwCfSu5oJcqIRb/BEeQA+IuaXrK/ U+IAnjAY+XAZNQcoWHNUIDaJGqdxikMY =du5P -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--