Re: [gentoo-user] LVM and moving things around

[Michael]

On Monday, 28 March 2022 04:59:04 BST Dale wrote:
> Michael wrote:
> > On Sunday, 27 March 2022 22:04:45 BST Dale wrote:
> >> That's sort of what I'm going to do.  I'm going to divide things into
> >> sections with some encrypted and some not.
> >
> > I wonder if all you want to do is to encrypt some directories on your
> > /home, then a different level of encryption would be more appropriate?
> > Instead of encrypting a whole block device, you could just encrypt a
> > directory tree or two, using ext4 encryption.  e4crypt has been kicking
> > around for a few years now and it is meant to be an improvement on
> > eCryptfs.
> >
> > https://lwn.net/Articles/639427/
> >
> > https://wiki.gentoo.org/wiki/Ext4_encryption
> >
> > WARNING:  I'm not qualified to speak about this topic because my
> > experience is limited, but I'm interested all the same in reading your
> > approach and other contributors advice.
>
> That is the basic plan.  I'll have /home as a normal open mount point.
> That way I can login without a encryption password being needed.  After
> that, I plan to have other mount point(s) that are encrypted.

OK, that's a different plan to what I'm talking about.  I am talking about 
filesystem based encryption.

You are talking about block device level encryption.  Whether these other 
mountpoints you want to encrypt are for normal partitions, LVM, what-ever, 
you're dealing with whole block devices and mechanisms for encrypting these 
block devices *before* a filesystem and data is even placed on them.

With a filesystem level encryption you will be using the kernel's native 
filesystem encryption and the fscrypt API to manage it.  The sys-fs/fscrypt 
userspace package can be used to manage the kernel based fscrypt API to 
encrypt/decrypt some directories selectively within a filesystem.  This can be 
set up to happen transparently via PAM, using the user's login, if desired.

You can read more about the kernel fscrypt mechanism here:

https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html

For how to set it up and run it from userspace details are here:

https://wiki.archlinux.org/title/Fscrypt


> It may be
> /home/dale/Data or something to that effect.  I'm still doing some
> checking but the normal non-encrypted stuff should easily fit on a 6TB
> drive without encryption.  I can then rebuild the two 8TB drives as
> encrypted mount points with a different volume group thingy.  When I
> boot up, I can login in as usual then decrypt the other mount point and
> access it as needed or close it and it be encrypted until needed.

If you have 8TB of data you want encrypted, then a block level encryption 
would make sense.  However, if you only have a few MB or GB of data to encrypt 
in a couple of directories, then it may be more appropriate to consider native 
filesystem encryption with fscrypt.


> I've considered just encrypting /home completely but I don't have the
> option of closing it while I'm logged into KDE.  KDE wouldn't be able to
> access /home/dale/.kde or .config plus if I leave Seamonkey open, it
> will want to store new emails to .mozilla as well.  So, some things need
> to be available and I'm not to worried about them being encrypted
> anyway.  So encrypting all of /home would be overkill plus would be a
> problem for some things too, such as Seamonkey and KDE.

With fscrypt you can run manually 'fscrypt lock Vault-for-Dale' and only the 
directory 'Vault-for-Dale' with any files in it will be encrypted.  All the 
remaining fs will be left as it was.

Anyway, I'm only mentioning this as an alternative to consider, in case it fits 
your use case better than buying more disks and whole block device encryption 
methods.