(24/N) There are some best practices that will make it easier to answer threat modeling question #3, "What are you going to do about it?". These will help you protect a wide range of assets by taking care of your devices, so let's look at them first:

1. Encrypt data at rest
2. Bootstrap your workplace
3. Actively maintain your devices
4. Secure your devices
5. Prepare for repair

1. Encrypt data at rest

What can you achieve with intermediate knowledge, without fully descending into the rat hole?

Caveat: this is best done when setting up #Linux on a new device. Modifying an existing installation on your own IMHO isn't advisable if you're not a seasoned user. If you still decide to venture into it, make SURE you have backed up all your assets, before following "howtos on the internet". You have been warned.

Likening your device to a medieval city:

1) Full-Disk Encryption (FDE) is like locking the "city gate". Most popular Linux distributions offer FDE during the installation process. FDE is also your last line of defense when your device gets stolen, or your disk fails and cannot be safely wiped before disposing of it. Use FDE. (Yes, technically, "Full" is not absolutely accurate. We'll leave it at that.)

2) Within your "city", there will likely be at least two "houses": the home of the admin account, and your personal home. Using FDE alone, the "doors" of these homes won't have any locks of their own. Possibly not a big deal with respect to the administrative account, but admins being able to access any of your non-public assets, even when you're not logged in, is probably not what you want.

While the specific steps depend on your preferred Linux distro, a "portable" solution is to create a separate, encrypted disk partition, and have it mounted as your user home directory, when you log in. That solution is based on cryptsetup and the pam_mount module, a nice tutorial example is:

• Linux Mint: https://cobertos.com/blog/post/linux-mint-luks-encrypted-user-home-directory

3) Within your "house", you may wish to have a locked "chest", e.g. for your #FYEO assets. There's essentially two options: a) a single, encrypted container file that acts as a "#vault" for your asset files; or b) an encrypted overlay file system that maintains an openly visible directory hosting your encrypted assets, including directory structures, in the background; and allows you to mount a decrypted counterpart, for working on your assets.

a) A "vault", being a single file, is easy to copy and carry around, on arbitrary storage media, e.g. USB sticks. It doesn't reveal too much about its contents, but resizing it takes a little effort. Also, you can't "incrementally backup" content changes, just copy the whole, changed vault.

A nice tutorial for creating and using a vault using plain, standard cryptsetup is https://opensource.com/article/21/4/linux-encryption by @seth . If you must have a GUI for creating and mounting vaults, look at #zuluCrypt https://mhogomchungu.github.io/zuluCrypt/ – IMHO the app is still in need of a little polish, though.

b) An encrypted overlay file system allows for incrementally backing up changed assets, but exposes considerable metadata (rough file sizes, directory structures, modification dates).

The most widely used package for this is probably #gocryptfs. Its "HowTo" is literally a one-pager: https://nuetzlich.net/gocryptfs/quickstart/

Start of this thread:
https://mastodon.de/@tuxwise/113503228291818865