Re: Unencrypted boot with encrypted root

[Pierre Neidhardt]

There is at least one benefit using ZFS: encrypted subvolumes (also
known as datasets).

Currently in Guix it's impossible to have a subvolume for the store and
an encrypted subvolume for /home.
In order to have an unencrypted root and an encrypted /home, we must put
them on different _partitions_ so that we can crypt /home with LUKS.
This has the big downside of imposing a fixed size at creation time.

With ZFS, it would be possible to an encrypted /home without encrypting
/gnu/store and without fixing the size at creation time.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Unencrypted boot with encrypted root

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> Have you tried to unlock a ZFS-encrypted home with pam_mount?
>
> I found these related links:
>
> https://blogs.oracle.com/solaris/user-home-directory-encryption-with-zfs-v2
>
> https://old.reddit.com/r/linuxquestions/comments/g7t38d/mounting_an_encrypted_zfs_home_filesystem_at_user/
>
> ZFS is not listed here:
> http://pam-mount.sourceforge.net/pam_mount.conf.5.html

No, I've never tried. In fact, I only tried ZFS once a few years ago,
and as for my use case I didn't see an advantage over BTRFS, I kept
using BTRFS.


signature.asc
Description: PGP signature

Re: Unencrypted boot with encrypted root

[Vagrant Cascadian]

On 2020-04-08, Ellen Papsch wrote:
> Am Dienstag, den 07.04.2020, 09:47 -0700 schrieb Vagrant Cascadian:
>> On 2020-04-07, Alex Griffin wrote:
>> > So we can put the key in its own initrd (outside of the store)
>> > 
>> 
>> I believe it's also possible for grub to provide the key
>> derived/decrypted from the passphrase entered at run-time
>> 
>
> These may be dangerous waters. The key file in initrd is like a house
> key under the mattress. A malicious process could look in the well
> defined place and exfiltrate the key. Think state trojan horses. A
> random name would not suffice, because other characteristics may help
> identifying the file (i.e. size).

The key for a LUKs volume is exposed in the running kernel and a
compromised root account can exfiltrate it... 


> Regarding passing on the key, you mean the master key? I don't know if
> it's possible. If it's documented and recommended, I'd say go for it.
> But keep in mind this is crypto we are talking about. If it's something
> hacky we're straying from the path and may be inadvertently opening up
> security holes. A security guru analysis would help.

It would reduce the attack surface by not asking for the passphrase
twice. You *have* to to it once from grub (presuming encrypted /boot),
so it's simply re-using the unlocked key...


> I think* Guix would burden itself too much with secrets. It's something
> for the user and the installer should just make it more convenient,
> with a nudge to a more secure setup. The key file should be stored in a
> user specified location, preferably a pen drive (which is otherwise not
> used). It can be removed, so no read can occur by arbitrary processes.
> A passphrase should be added as backup.

No need to store the key file in anything but ephemeral ram, ideally
where it wouldn't be swapped to disk, in the running kernel...


I'll look into the actual implementation of what I'm talking about
rather than rambling on further about theoretical possibilities.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Unencrypted boot with encrypted root

[Alex Griffin]

On Wed, Apr 8, 2020, at 12:25 PM, Ellen Papsch wrote:
> These may be dangerous waters. The key file in initrd is like a house
> key under the mattress. A malicious process could look in the well
> defined place and exfiltrate the key. Think state trojan horses. A
> random name would not suffice, because other characteristics may help
> identifying the file (i.e. size).

What's the threat model here? For me, an encrypted disk is only meant to 
protect my data at rest. If a malicious process is already running on my system 
as root, then I don't care if they can exfiltrate the key.

-- 
Alex Griffin

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Am Dienstag, den 07.04.2020, 22:19 +0200 schrieb Ludovic Courtès:
> Ellen Papsch  skribis:
> 
> 
> Sure, but what happens when you reconfigure?  You still need to have
> that file around so it can be added to the initrd.
> 

Does it really have to be added to initrd? From my other reply:

> These may be dangerous waters. The key file in initrd is like a house
> key under the mattress. A malicious process could look in the well
> defined place and exfiltrate the key. Think state trojan horses. A
> random name would not suffice, because other characteristics may help
> identifying the file (i.e. size).

> I think* Guix would burden itself too much with secrets. It's
> something for the user and the installer should just make it more
> convenient, with a nudge to a more secure setup. The key file should
> be stored in a user specified location, preferably a pen drive (which
> is otherwise not used). It can be removed, so no read can occur by
> arbitrary processes. A passphrase should be added as backup.
> 
> (*) as non-guru

reconfigure would not have to touch the file at all, if it were a user
supplied file name. I'm aware other files are often put in the store by
references in operating-system (or inlined). The secrets file on the
other hand should just be assumed to be there. Initrd should try to
mount the drive.

Best regards

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Hi,

Am Dienstag, den 07.04.2020, 09:47 -0700 schrieb Vagrant Cascadian:
> On 2020-04-07, Alex Griffin wrote:
> > So we can put the key in its own initrd (outside of the store)
> > 
> 
> I believe it's also possible for grub to provide the key
> derived/decrypted from the passphrase entered at run-time
> 

These may be dangerous waters. The key file in initrd is like a house
key under the mattress. A malicious process could look in the well
defined place and exfiltrate the key. Think state trojan horses. A
random name would not suffice, because other characteristics may help
identifying the file (i.e. size).

Regarding passing on the key, you mean the master key? I don't know if
it's possible. If it's documented and recommended, I'd say go for it.
But keep in mind this is crypto we are talking about. If it's something
hacky we're straying from the path and may be inadvertently opening up
security holes. A security guru analysis would help.

I think* Guix would burden itself too much with secrets. It's something
for the user and the installer should just make it more convenient,
with a nudge to a more secure setup. The key file should be stored in a
user specified location, preferably a pen drive (which is otherwise not
used). It can be removed, so no read can occur by arbitrary processes.
A passphrase should be added as backup.

(*) as non-guru

With or without key on a drive, passing on the master key would help
avoiding waiting a second time for decryption. It would certainly be
nice if it's feasible.

Best regards

Re: Unencrypted boot with encrypted root

[Alex Griffin]

On Wed, Apr 8, 2020, at 7:57 AM, Pierre Neidhardt wrote:
> Do you have a working example of this for Guix?

Unfortunately not. I do have an old NixOS config[1] where I set things up like 
this, if what you're looking for is a proof-of-concept.

-- 
Alex Griffin

[1]: 
https://gitlab.com/ajgrf/dotfiles/-/blob/1e17dac3cda00af68772dc22731ac0880d280b9c/.nixpkgs/antares.nix

Re: Unencrypted boot with encrypted root

[Ludovic Courtès]

Ellen Papsch  skribis:

> Does it have to go through the store? I imagine key generation would be
> done by the installer, not guix system init.

Sure, but what happens when you reconfigure?  You still need to have
that file around so it can be added to the initrd.

Ludo’.

Re: Unencrypted boot with encrypted root

[Vagrant Cascadian]

On 2020-04-07, Alex Griffin wrote:
> On Tue, Apr 7, 2020, at 9:46 AM, Ludovic Courtès wrote:
>> The difficulty is that any file traveling through the store is
>> world-readable.  It’s hard to avoid.
>
> If we can create the key file outside of the store, then GRUB is capable of 
> being passed multiple initrds. So we can put the key in its own initrd 
> (outside of the store), continue to generate the normal initrd in /gnu/store, 
> and pass both of them to GRUB. The key never enters the store in any way.
>
> The result is that the user only needs to enter a password into GRUB, because 
> GRUB then passes the key file to the kernel.

I believe it's also possible for grub to provide the key
derived/decrypted from the passphrase entered at run-time, obviating the
need for a separate key entirely. I don't have details on how to do
this, but I *think* that's what recent Debian installs do... it
certainly would simplify key slot management issues.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Unencrypted boot with encrypted root

[Alex Griffin]

On Tue, Apr 7, 2020, at 9:46 AM, Ludovic Courtès wrote:
> The difficulty is that any file traveling through the store is
> world-readable.  It’s hard to avoid.

If we can create the key file outside of the store, then GRUB is capable of 
being passed multiple initrds. So we can put the key in its own initrd (outside 
of the store), continue to generate the normal initrd in /gnu/store, and pass 
both of them to GRUB. The key never enters the store in any way.

The result is that the user only needs to enter a password into GRUB, because 
GRUB then passes the key file to the kernel.

-- 
Alex Griffin

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Hi,

Am Dienstag, den 07.04.2020, 11:46 +0200 schrieb Ludovic Courtès:
> Hi,
> 
> Ellen Papsch  skribis:
> 
> > Am Samstag, den 04.04.2020, 12:18 +0200 schrieb pelzflorian
> > (Florian
> > Pelz):
> > > Could key files help in passing the passphrase on to the
> > > Linux kernel?  The Arch Wiki says this: [...]
> > > 
> > 
> > If the installer would support an external medium for the file,
> > that would be best (IMHO).
> 
> The difficulty is that any file traveling through the store is
> world-readable.  It’s hard to avoid.
> 

Does it have to go through the store? I imagine key generation would be
done by the installer, not guix system init. That would be much in the
same way that the installer creates partitions, while system init (or
reconfigure) doesn't touch partitions, only uses existing references.
In that sense, the installer would create the file from /dev/random or
urandom and place the reference in operating-system.

It would also allow manual installations to retain flexibility
configuring encryption.

Best regards

Re: Unencrypted boot with encrypted root

[Ludovic Courtès]

Hi,

Ellen Papsch  skribis:

> Am Samstag, den 04.04.2020, 12:18 +0200 schrieb pelzflorian (Florian
> Pelz):
>> Could key files help in passing the passphrase on to the
>> Linux kernel?  The Arch Wiki says this: [...]
>> 
>
> The key file would be another means of decrypting the master key, if I
> understand LUKS correctly. It would be independent of the passphrase.
> (In LUKS terminology, two slots are used).
>
> It would definitely help usability not having to enter a passphrase
> twice. The GUI/TUI installer should take care generating the file and
> ensuring strict permissions, so user processes cannot read it. There is
> still some risk, because root processes could read it. If the installer
> would support an external medium for the file, that would be best
> (IMHO).

The difficulty is that any file traveling through the store is
world-readable.  It’s hard to avoid.

Ludo’.

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Am Samstag, den 04.04.2020, 12:18 +0200 schrieb pelzflorian (Florian
Pelz):
> Could key files help in passing the passphrase on to the
> Linux kernel?  The Arch Wiki says this: [...]
> 

The key file would be another means of decrypting the master key, if I
understand LUKS correctly. It would be independent of the passphrase.
(In LUKS terminology, two slots are used).

It would definitely help usability not having to enter a passphrase
twice. The GUI/TUI installer should take care generating the file and
ensuring strict permissions, so user processes cannot read it. There is
still some risk, because root processes could read it. If the installer
would support an external medium for the file, that would be best
(IMHO).

Best regards

Re: Unencrypted boot with encrypted root

[pelzflorian (Florian Pelz)]

Thank you Ellen for the good summary.  I knew most but in less detail.

On Sat, Apr 04, 2020 at 10:12:46AM +0200, Ellen Papsch wrote:
> Am Freitag, den 03.04.2020, 21:44 +0200 schrieb pelzflorian (Florian
> Pelz):
> > But it would still be possible for an attacker […]
> Yes, though it should not be so easy like with unprotected /boot
> partition.

So the better solution would be a better GRUB instead of unprotected
/boot.  Could key files help in passing the passphrase on to the Linux
kernel?  The Arch Wiki says this:
.

Keyboard layouts then will only all work properly everywhere once
fixed in GRUB.

Regards,
Florian

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Am Freitag, den 03.04.2020, 21:44 +0200 schrieb pelzflorian (Florian
Pelz):
> 
> So using a single encrypted partition instead of separate /boot
> protects from script kiddies (siblings/“friends”?) with hardware
> access that know how to put their own grub.cfg on an unencrypted
> /boot
> partition and then wait for you to unsuspectingly use your machine.
> 

Yes, it is better known as "evil maid attack", because the original
thought included a hotel room[0].

> But it would still be possible for an attacker to flash or replace
> the
> motherboard’s UEFI, or perhaps the part of GRUB installed on the
> unaltered motherboard would willingly load a manipulated hard disk?
> Or just install a keylogger.
> 

Yes, though it should not be so easy like with unprotected /boot
partition.

You have these boot stages in a modern UEFI system (just numbered
sequentially):

- hardware initialization
- stage 0, which is a minimal bootloader including the Secure Boot key
on ROM.
- stage 1, which is Management Engine on Intel platforms or Platform
Security Processor on AMD platforms. Some of it is on ROM, while most
can be (not easily) flashed. ME is a Minix derivate with its own little
processor (ARM IIRC).
- stage 2, which is your UEFI BIOS.
- stage 3, which is the program that gets put in the /boot/efi
directory and registered with the BIOS, i.e. GRUB.
- stage 4-n, Guix!

If you are interested in the flaws of stage 1, check out [1] and [2].
[3] is very interesting too, as it not only presents hardware flaws but
also suggests possible way forward. (These are the same video URLs I
initially posted.)

Breaking any earlier stage gives you control over the later stages.

The general gist is that all common (consumer) hardware is flawed and
with it the software that runs on it. That makes free hardware ever
more important. It's also why people are interested in breaking stage
1; not so much for attack, but because it is closely linked to the
hardware and prevents their freedom.

Regards,
Ellen

[0] https://en.wikipedia.org/wiki/Evil_maid_attack
[1] https://media.ccc.de/v/36c3-10694-intel_management_engine_deep_dive
[2] 
https://media.ccc.de/v/thms-38-dissecting-the-amd-platform-security-processor
[3] 
https://media.ccc.de/v/36c3-10690-open_source_is_insufficient_to_solve_trust_problems_in_hardware

Re: Unencrypted boot with encrypted root

[Guillaume Le Vaillant]

Ellen Papsch  skribis:

> Am Freitag, den 03.04.2020, 18:13 +0200 schrieb Pierre Neidhardt:
>>
>> 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 use the pam-mount service to mount paritions when users log in.

There's an example in the manual for a user mounting their encrypted
'/home/user' directory. And if the user's password matches one of the
passwords that can decrypt the partition, you don't have to enter it
twice.


signature.asc
Description: PGP signature

Re: Unencrypted boot with encrypted root

[pelzflorian (Florian Pelz)]

On Fri, Apr 03, 2020 at 05:44:13PM +0200, Ellen Papsch wrote:
> To make it harder, we leave /boot encrypted. Now the attacker plants
> their malware further down the stack: they replace the BIOS. Boom, you
> are owned! :-)

So using a single encrypted partition instead of separate /boot
protects from script kiddies (siblings/“friends”?) with hardware
access that know how to put their own grub.cfg on an unencrypted /boot
partition and then wait for you to unsuspectingly use your machine.

But it would still be possible for an attacker to flash or replace the
motherboard’s UEFI, or perhaps the part of GRUB installed on the
unaltered motherboard would willingly load a manipulated hard disk?
Or just install a keylogger.

So using the same boot partition as is done currently has

Pro: script kiddie protection

Con: passphrase must be entered twice; also entering the passphrase in
GRUB may use the wrong keyboard layout

Regards,
Florian

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

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

Re: Unencrypted boot with encrypted root

[Ellen Papsch]

Hi,

Am Donnerstag, den 02.04.2020, 10:59 +0200 schrieb Pierre Neidhardt:
> Hi!
> 
> I've followed the doc / template to set up an encrypted system on my
> laptop:
> 
> --8<---cut here---start->8---
>   (mapped-devices
>(list (mapped-device
>   (source (uuid "12345678-1234-1234-1234-123456789abc"))
>   (target "my-root")
>   (type luks-device-mapping
> 
>   (file-systems (append
>  (list (file-system
>  (device (file-system-label "my-root"))
>  (mount-point "/")
>  (type "ext4")
>  (dependencies mapped-devices))
>(file-system
>  (device (uuid "1234-ABCD" 'fat))
>  (mount-point "/boot/efi")
>  (type "vfat")))
>  %base-file-systems))
> --8<---cut here---end--->8---
> 
> Problem is, I get prompted for the LUKS password twice: once before
> GRUB
> starts and once when booting an OS entry.
> 
> This is rather annoying (and quite slow by the way, it takes some 10-
> 20
> seconds) and probably not too useful.
> 
> Is it possible to prompt for the password only once?
> 
> I suppose that one way to do this is to make /boot a separate file
> system beside /boot/efi.
> All in all, the configuration would look like this:
> 
> --8<---cut here---start->8---
>   (mapped-devices
>(list (mapped-device
>   (source (uuid "12345678-1234-1234-1234-123456789abc"))
>   (target "my-root")
>   (type luks-device-mapping
> 
>   (file-systems (append
>  (list (file-system
>  (device (file-system-label "my-root"))
>  (mount-point "/")
>  (type "ext4")
>  (dependencies mapped-devices))
>(file-system
>  (device (file-system-lavel "boot")
>  (mount-point "/boot")
>  (type "ext4"))
>(file-system
>  (device (uuid "1234-ABCD" 'fat))
>  (mount-point "/boot/efi")
>  (type "vfat")))
>  %base-file-systems))
> --8<---cut here---end--->8---
> 
> We should probably update the doc and templates to explain this
> subtlety, since mistakes in the partition design are hard to recover
> after the fact :)
> 
> Insights?
> 


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. A nefarious law enforcement agency may seize your
computer and give it back, seemingly without modifications. Boom, you
are owned!

To make it harder, we leave /boot encrypted. Now the attacker plants
their malware further down the stack: they replace the BIOS. Boom, you
are owned! :-)

To make it harder, we ensure to have UEFI BIOS and enable Secure Boot.
Now the attacker exploits the Intel Management Engine (ME) flaws[0].
AMD is flawed as well[1]. Boom, you are owned!

To make it harder, we exploit the flaws ourselves and replace most of
ME with an (of course) most secure BIOS. Now the attacker goes even
further down the stack and implants their malware in the PCB[2]. Boom,
you are owned!

No matter what you do, you are owned. That doesn't even touch another
great attack surface that an internet connected computer is. For
maximum security, you should dig a hole, plant a metal cage that can
hold the computer and completely autonomous power source (think
plutonium), then have a tor-like connection of your monitor, mouse and
keyboard to that machine (and a big red button that lets you destroy
the hops).

On a more serious note and to answer your question, unencrypted /boot
is an option. Another is to have a key file on an external medium. This
doesn't avoid the second wait. The long wait may be due to --iter-time
option to cryptsetup luksFormat. I haven't looked what the default is
in Guix. The Grub decryption code is also purported to be slow [no
source].

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.

Don't think you are in danger of being targeted? Well, you already are!
Your mail often gets into my spam folder because of "suspicious TLD
.xyz". That should be very telling ;-))

Best regards
Ellen

[0] https://media.ccc.de/v/36c3-10694-intel_management_engine_deep_dive
[1] 
https://media.ccc.de/v/thms-38-dissecting-the-amd-platform-security-processor
[2] 

Re: Unencrypted boot with encrypted root

[pelzflorian (Florian Pelz)]

On Thu, Apr 02, 2020 at 10:59:30AM +0200, Pierre Neidhardt wrote:
> I suppose that one way to do this is to make /boot a separate file

Yes please, this is also an issue in

https://issues.guix.info/issue/40273#24

I believe an unencrypted GRUB file-system would be a better default.

Regards,
Florian