Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by Fnord666 on Friday May 01 2020, @11:04AM   Printer-friendly
from the resistance-is-futile.-/home-will-be-assimilated dept.

Good News:

Linux home directory management is about to undergo major change:

With systemd 245 comes systemd-homed. Along with that, Linux admins will have to change the way they manage users and users' home directories.

[...] Prior to systemd every system and resource was managed by its own tool, which was clumsy and inefficient. Now? Controlling and managing systems on Linux is incredibly easy.

But one of the creators, Leannart Poettering, has always considered systemd to be incomplete. With the upcoming release of systemd 245, Poettering will take his system one step closer to completion. That step is by way of homed.

[...] let's take a look at the /home directory. This is a crucial directory in the Linux filesystem hierarchy, as it contains all user data and configurations. For some admins, this directory is so important, it is often placed on a separate partition or drive than the operating system. By doing this, user data is safe, even if the operating system were to implode.

However, the way /home is handled within the operating system makes migrating the /home directory not nearly as easy as it should be. Why? With the current iteration of systemd, user information (such as ID, full name, home directory, and shell) is stored in /etc/passwd and the password associated with that user is stored in /etc/shadow. The /etc/passwd file can be viewed by anyone, whereas /etc/shadow can only be viewed by those with admin or sudo privileges.

[...] Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. That record will contain all user information such as username, group membership, and password hashes.

Each user home directory will be linked as LUKS-encrypted containers, with the encryption directly coupled to user login. Once systemd-homed detects a user has logged in, the associated home directory is decrypted. Once that user logs out, the home directory is automatically encrypted.

[...] Of course, such a major change doesn't come without its share of caveats. In the case of systemd-homed, that caveat comes by way of SSH. If a systemd-homed home directory is encrypted until a user successfully logs in, how will users be able to log in to a remote machine with SSH?

The big problem with that is the .ssh directory (where SSH stores known_hosts and authorized_keys) would be inaccessible while the user's home directory is encrypted. Of course Poettering knows of this shortcoming. To date, all of the work done with systemd-homed has been with the standard authentication process. You can be sure that Poettering will come up with a solution that takes SSH into consideration.

Older articles:

Will systemd be considered complete once the kernel and boot loader have been absorbed into systemd?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by hendrikboom on Friday May 01 2020, @05:26PM (1 child)

    by hendrikboom (1125) Subscriber Badge on Friday May 01 2020, @05:26PM (#989056) Homepage Journal

    Yes. That's an issue.

    Does Devuan handle that encryption system?

    I did not encrypt my hard drives. For me, losing the decryption key is a bigger risk than leaking the data.

    -- hendrik

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1) by DECbot on Friday May 01 2020, @07:10PM

    by DECbot (832) on Friday May 01 2020, @07:10PM (#989116) Journal

    So, the laptop was built back in the ZFS on Linux in the ZFS 6.9 era I believe, so encryption was done by LUKS. I've got the details of how I got that working in my journal. If I ever redo it, I'd try to use the baked in ZFS encryption now that it's released.
     
    GELI is a whole other story as that is a BSD only thing. That was the way to do ZFS+encryption with BSD before ZFS had native encryption. There has been some toy applications on Github for decrypting Geli encrypted volumes on Linux, but nothing with robust testing. To safely get the data, I would either have to install Devuan on a new disk and run BSD in a virtual machine to serve the data or detach one encrypted partition from the zvol, format, and then reattach it to the zvol as a new, never been encrypted partition, and then after that resilver the zpool. Once the resilver is done, repeat that procedure for the other 3 drives. No matter how I decide to do it, I am very tempted to add two additional disks as some sort of mirror for holding the os, and leaving the data on the current zpool. What's nice about the ZFS native encryption is I can apply the encryption after the device creation, so I don't have to recreate my dataset. Here's the info: ZFS encryption preview [heckel.io]. Note, this blog dates back to 2017 where as ZFS encryption just landed as stable some time last year if I'm recalling things correctly.

    --
    cats~$ sudo chown -R us /home/base