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_
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_fi
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/decrypt
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, be
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 m
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-
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/dotfi
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’.
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 mult
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 o
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
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
>
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 in
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
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
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
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 fr
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 tha
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
> (sourc
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,
Flori
20 matches
Mail list logo
