From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ellen Papsch Subject: Re: Unencrypted boot with encrypted root Date: Fri, 03 Apr 2020 19:16:34 +0200 Message-ID: References: <87ftdmi7pp.fsf@ambrevar.xyz> <17c316adc8485d1f09f70d291cfaad50258c6c1f.camel@wine-logistix.de> <87k12wsg36.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44108) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKPvr-0002nf-0z for guix-devel@gnu.org; Fri, 03 Apr 2020 13:16:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKPvo-0004hL-JA for guix-devel@gnu.org; Fri, 03 Apr 2020 13:16:37 -0400 Received: from dedi718.your-server.de ([78.46.1.118]:38966) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jKPvo-0004g3-BT for guix-devel@gnu.org; Fri, 03 Apr 2020 13:16:36 -0400 In-Reply-To: <87k12wsg36.fsf@ambrevar.xyz> 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-mx.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt , guix-devel@gnu.org Am Freitag, den 03.04.2020, 18:13 +0200 schrieb Pierre Neidhardt: > Ellen Papsch writes: > > > leaving /boot unencrypted allows attackers to plant malware > > relatively > > easy. They can mount the partition without ado and replace the > > kernel > > with a malicious one. > > How can you do that if the root partition is encrypted? > Your partition table would have at least two partitions: no, type, mount point 0, Linux fileystem, /boot 1, Linux LUKS, / /boot is completely independent of the root partition. Other distributions copy the kernel to /boot. I just looked in GuixSD and grub.cfg references kernel and initramfs in /gnu/store. Which is good for kernel modification prevention but also prevents separate /boot. Florian links to #40273, which discusses copying the files out of the store. That would turn the tables. When turned, to plant the malware, you would boot another system from CD, USB or network. If the BIOS (and boot) is locked down, you would extract the hard drive. That's where the cage comes in. > > > For a long time I personally used root encrypted systems and found > > the > > hassle not worth it. Encrypting /home and external hard drives > > should > > cut it. If you suspect the machine has been tampered with, don't > > boot > > don't touch it. Even the hard disk firmware may have been modified. > > My main motivation is that if my laptop gets stolen or lost, I don't > want > anyone to access my personal data. > > Encrypted /home is fine for this purpose. > I would second that, although there is a chance data may leak to /var. That would depend on the program. While separate /boot is not possible, encrypting /home and /var may be the convenient compromise to mitigate a stolen/lost machine. (though convenience is again degraded by two passphrase prompts and wait times) > By the way, is it possible to use the user password to unlock the > $HOME partition? > AFAIK GNU/Linux userland does not support it. GDM or another login manager would have to integrate that feature somehow. Maybe (maybe) there is some PAM way, but that's a wild guess. You can avoid a passphrase prompt by using a key file on an external medium. That poses the danger of the medium failing, make sure to have a passphrase in addition (and not forget that :-). From a quick glance at the manual, there seems no way of specifying a key file, though maybe if you dig deeper... Regards