𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

       🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆. 
 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍 

Ceterum Lemmi necessitates reactiones

  • 2 Posts
  • 139 Comments
Joined 3 years ago
cake
Cake day: August 26th, 2022

help-circle


  • OnlyOffice is a Russian company. Some people might care about the latter part.

    The connection between OnlyOffice and Russia has caused some controversy. The company has moved headquarters and attempted to hide its Russian ties through shell companies. The company develops its product in Russia and presents itself in the Russian market as a Russian company. For this reason some Ukrainian businesses have moved away from OnlyOffice.

    Wikipedia has more info (with references) for the curious.







  • I gave my dad one of my spare laptops four years ago; it had never had Windows on it (being from the halcyon days when Dell sold laptops with linux pre-installed), so I put Mint on it for him.

    Early this year he called and said one of the keys stopped working so he’d bought a newer, used laptop and could I help him put Linux on it, because that’s what he was used to. Over the phone, I helped him download and burn a new Mint image from his ancient desktop, and verbally walked him through switching the bios to boot from the USB, and through the Mint install menus.

    Since then, he’s called me once for technical support for getting his printer connected.

    Dad’s in his 80’s and was a cop with an associate’s degree; he’s never claimed to be a brainiac. That is what convinced me Linux is ready for anyone, but that the choice of distribution is important. I think dad never upgrades or installs new software, but that’s OK. I have to update and reboot every week because I’m stupidly loyal to Arch.

    I’m sorry that your mom had a bad experience; that’s super frustrating.


  • The Remarkable 2 is fantastic. You can ssh into it, and scp from it. There are some filesystem layout quirks, but it’s good. Peerless writing experience. Great battery. Plenty storage. Large screen. No backlight, sadly. Good for

    • taking notes
    • reading & annotating PDFs
    • reading technical books, with illustrations and diagrams
    • reading graphic novels

    Not so good for reading for pleasure, like fiction. It’s too big. It’s best for active reading and writing.

    I have a Kobo Aura H2O for recreational reading and travel. Massive memory and an SD expansion slot. Backlight. Pretty indestructible, I read it in the jacuzzi.






  • No solution I’ve found, but I’ve been working on this myself. As I see it, there are two situations, and four categories of data:

    I. My wife survives me II. We both die, e.g. in a car

    • Digital media
    • Financial accounts
    • Subscriptions
    • Physical possessions

    I’ve been thinking about getting an M-Disk writer for media, because ultimately, backing up to B2 is fine until I’m gone. Family members will need physical media for the photos and stuff.

    For secrets, I’m planning using SSSS. Keys will be given to members on each side of my wife’s and my families. If we both die, they’ll have to get together, put their keys together, and decrypt the KeePass DB.

    The online accounts are almost all financial; those are in a KeePass DB. My wife already has access to all of that through power is attorney, and if we both go, it’s SSSS for the family.

    The third data category are accounts and services that will be to be stopped. I don’t subscribe to much, but the VPS provider and B2 will have to be terminated, and a document with instructions and with the credentials is in the SSSS archive.

    The final category are assets: home, mortgage info, where and what the M-Disks are, a copy of the will that deals with all of the valuables, and any notes about anything not covered in the will. That’s in documents in the SSSS archive.

    I still have to put the archive together. I’ve been working toward a state where all of the secrets are in a cryptfs that’s shared on the LAN and automatically encrypted with SSSS and synced to a share. Once I have that automated, I’ll communicate out the SSSS keys and a how-to document.

    In some ways, it was easier when you just died and your kids fought over the china. But I have a plan.



  • Ok, I went and read some more about it, and you can manage keys with the kernel user session keyring. So it’s possible.

    It brought me back around to why systemd is so shitty.

    Session Keyring (Rejected)

    This strategy involves placing all keys for fscrypt in KEY_SPEC_SESSION_KEYRING. Using the current session keyring means that fscrypt will not need elevated privileges to place keys in this keyring, eliminating the need for a setuid binary. It also means that if something like pam_keyinit is used, the keys will be inherited across things like sudo.

    However, this strategy has a few significant downsides that led to it not being used. The first issue is that keys unlocked in one session for a user are (sometimes) not accessible to the user in other sessions. This can create confusion for users unable to access certain directories. However, the bigger problem is that systemd is incompatible with use of the system keyring. The systemd maintainers are of the reasonable position that the session keyring just shouldn’t be used.

    fscrypt

    Emphasis mine. Because the user session keyring is incompatible with systemd, the Poetterites say it shouldn’t be used.

    The only way to handle keys securely Ok base Linux shouldn’t be used because it’s incompatible with systemd. What a way to see the world: so convinced in the superiority of your monolithic monster system that you argue against an immediately available way of improving security.

    It’s incompatible, by the way, because systemd doesn’t run user jobs in the user’s session, but in parallel sessions. This means that, if you use systemd, you can’t use the most secure way of handling secrets with fscrypt, the kernel user session keyring.



  • Is it possible to configure the kernel to allow access to decrypted contend only through the user session?

    Theoretically, kernel keys can be set to be readable only by the user session, and in an uncompromised root is not able to read those keys. I can imagine a filesystem encryption design that uses a user session key to en/decrypt data on the fly using a user session key, such that not even root or a process in another user session could read the mounted filesystem.

    Does such a system exist? As I understand, this is not the way dm-crypt or LUKS work. FDE and TPM are still vulnerable to hacking while everything is running, unlocked, and mounted.