Stories
Slash Boxes
Comments

SoylentNews is people

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: 5, Funny) by The Mighty Buzzard on Friday May 01 2020, @11:43AM (29 children)

    What the hell, Leannart? Why would you store important information in a human readable form like json when you could store it in a binary container that requires a specific executable tool to interact with?

    --
    My rights don't end where your fear begins.
    Starting Score:    1  point
    Moderation   +4  
       Insightful=1, Funny=3, Total=4
    Extra 'Funny' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 5, Insightful) by Azuma Hazuki on Friday May 01 2020, @01:02PM

    by Azuma Hazuki (5086) on Friday May 01 2020, @01:02PM (#988914) Journal

    Fecking LOL. +1 Funny, though it's also tragic.

    --
    I am "that girl" your mother warned you about...
  • (Score: 3, Interesting) by janrinok on Friday May 01 2020, @01:08PM (23 children)

    by janrinok (52) Subscriber Badge on Friday May 01 2020, @01:08PM (#988920) Journal

    store it in a binary container that requires a specific executable tool to interact with

    You've just answered your own question. It would require a specific executable tool.

    Your drive can be encrypted. You can move it to another computer that you have never used before and plug it in, unlock the encryption, and it can automatically create your user credentials on the new machine. Your files remain secure. Only you have access to them because they are now protected by your user ID and the file permissions. You can work on your files on this computer and then simply unplug the drive and take your data away safely leaving nothing on the computer that you used.

    His proposal also allows for a system that computers can prevent the issuing of administrative permissions to any drives mounted this way to protect the computer itself.

    You don't have to like it - in fact, I'm fairly sure that you won't - but have you got a better solution to this problem? Because here is your opportunity to be very wealthy and solve a long-established problem with data security.

    • (Score: 4, Informative) by tekk on Friday May 01 2020, @01:14PM (1 child)

      by tekk (5704) Subscriber Badge on Friday May 01 2020, @01:14PM (#988928)

      The joke is that Systemd likes to use opaque binary formats which require special tools where they used to just be text files.

    • (Score: 5, Insightful) by Grishnakh on Friday May 01 2020, @03:06PM (12 children)

      by Grishnakh (2831) on Friday May 01 2020, @03:06PM (#988998)

      but have you got a better solution to this problem?

      What if I don't consider this a problem at all? I have no desire at all to move my files, encrypted, to another computer I've never used before.

      However, I absolutely do require that I can log into my account with SSH, which apparently is a no-go with this "solution".

      The problem here is that this "solution" breaks existing use-cases, in favor of a different use-case that they haven't shown that anyone really needs.

      • (Score: 0) by Anonymous Coward on Friday May 01 2020, @04:25PM (2 children)

        by Anonymous Coward on Friday May 01 2020, @04:25PM (#989025)

        I like systemd and use systemd, but yes I don't see any value in homed/homectl.

        Assuming they get SSH working, I can see this as something acceptable to use but I don't see why anyone would actually want it. Maybe, maybe this could be useful in enterprise environments. Maybe homed/homectl would make it easier to have a school or business environment in which any user can login on any machine and use it as though it has been their own machine all along. Of course there are dozens of architectural ways to tackle that problem and thousands of technologies you can use, I'm not at all sold that this is a desirable solution.

        • (Score: 3, Informative) by PocketSizeSUn on Friday May 01 2020, @05:31PM

          by PocketSizeSUn (5340) on Friday May 01 2020, @05:31PM (#989061)

          Those environments use LDAP where this solution is both redundant, pointless, and broken.

        • (Score: 2) by janrinok on Saturday May 02 2020, @07:39AM

          by janrinok (52) Subscriber Badge on Saturday May 02 2020, @07:39AM (#989371) Journal

          The use of homed is at the user's discretion. You can keep your SSH access without making any changes to your system and forego the homed.

          The major systemd distros have insisted on this because many people rely on it.

      • (Score: 4, Insightful) by NotSanguine on Friday May 01 2020, @08:41PM (7 children)

        However, I absolutely do require that I can log into my account with SSH, which apparently is a no-go with this "solution".

        Apparently, TFS (and likewise TFA) has that bit wrong.

        According to the homectl man page [freedesktop.org]:

        --ssh-authorized-keys=KEYS

                Either takes a SSH authorized key line to associate with the user record or a "@" character followed by a path to a file to read one or more such lines from. SSH keys configured this way are made available to SSH to permit access to this home directory and user record. This option may be used more than once to configure multiple SSH keys.

        Just to clarify, I'm not advocating wide adoption of systemd-homed. In fact, I'm not at all sold on the purported use case at all.

        It seems to me that it would be both simpler and more useful to just set ownership on portable files to be the same as the logged-in user plugging in the device with the files on them.

        This would be a simple file system shim which wouldn't require creation of a parallel set of data and tools to manage portable user data.

        If one *really* wanted to have an entire user configuration environment stored on a USB key or similar, an additional login shim could detect such a portable store at login and ask the user if they wished to use the portable storage as a home directory.

        What's more, storing independent user configuration information on a portable device opens up serious InfoSec issues. Especially since such data must be unencrypted on the device in order to configure the system to accept *unknown* logins onto arbitrary systems.

        What could go wrong? I'd elucidate, but the max comment size here would be easily exceeded.

        I'm curious. Can *anyone* present a use case that would *require* the use of something like systemd-homed?

        N.B.: I use systemd on the systems I manage, mostly without issue. But this seems like a disaster waiting to happen.

        --
        No, no, you're not thinking; you're just being logical. --Niels Bohr
        • (Score: 4, Insightful) by digitalaudiorock on Friday May 01 2020, @09:22PM (5 children)

          by digitalaudiorock (688) on Friday May 01 2020, @09:22PM (#989202) Journal

          Wow...I do NOT get how that --ssh-authorized-keys option is supposed to work. As I understand it, because the home is encrypted until you've logged in, it's impossible to read ~/.ssh which IS what the ssh daemon will assume(??). So that option would have to specify a keys file somewhere else?...where and with what ownership/permissions. And again most importantly, how is ssh itself going to look there? Can't make any sense out of that one.

          Everything I read indicates that ssh just can't work, at least not unless the ssh devs made changes the (hopefully) would refuse to consider. Sounds like that option is a pipe dream. This is probably the silliest and least useful change those ass-hats have come up with so far.

          Tom

          • (Score: 2, Insightful) by DECbot on Friday May 01 2020, @10:03PM

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

            What makes you think there will ever be an openssh solution? I'm betting the solution will simply be systemd-sshd and sshdctl to manage ssh connections and configuration. Not sure what this will look like, but I doubt it will be binary data or INI files or JSON or encrypted directories... It's got to be unique. Oh, we haven't done a distributed database yet. That's the method, ssh login information will be stored in a distributed no-sql database with custom btree topology. /s

            --
            cats~$ sudo chown -R us /home/base
          • (Score: 2) by NotSanguine on Saturday May 02 2020, @02:28AM (2 children)

            Wow...I do NOT get how that --ssh-authorized-keys option is supposed to work. As I understand it, because the home is encrypted until you've logged in, it's impossible to read ~/.ssh which IS what the ssh daemon will assume(??). So that option would have to specify a keys file somewhere else?...where and with what ownership/permissions. And again most importantly, how is ssh itself going to look there? Can't make any sense out of that one.

            A fair point. Which made me wonder how exactly that might work.

            As I was reading through this [reddit.com] and saw this comment [reddit.com] which suggests the following:

            This is not a problem at all. You don't need to store your authorized public keys in home directory. Read up sshd_config manpage and search for AuthorizedKeysFile and AuthorizedKeysCommand directives.

            Since the host in question must run an instance of sshd to which the client can connect, you can store keys *on the host* for a specified set of users by specifying an absolute pathto such keys vs. one relative to the (still encrypted) home directory in the sshd configuration That wouldn't support an arbitrary set of users, but is probably workable for the client/desktop use case Poettering discusses [reddit.com].

            All that said, I still think it's a stupid idea. Given the source, I'm not very surprised.

            --
            No, no, you're not thinking; you're just being logical. --Niels Bohr
            • (Score: 1) by DECbot on Saturday May 02 2020, @06:45AM (1 child)

              by DECbot (832) on Saturday May 02 2020, @06:45AM (#989355) Journal

              While I like my distributed database solution for ssh keys the sister post, I think the simple solution would be to stick the authorized machines and public ssh keys in the json file with user id and password and keep the private ones in ~/.ssh. The question is: will openssh bend to Pottering and look in new-standard ways in shared json config files for public keys or will he make his own implementation of sshd to get the required changes done? Of course, RH may come down and say "We don't need to reinvent ssh. Openssh is sacrosanct and doesn't need to change--we just need all the distros to change where sshd must look for keys via the configs. Therefore, only users that can use ssh are those blessed by an admin adding their keys and authorized machines to the systemd approved /etc/sshd/keys/userkeys and /etc/sshd/user/authorizedmachines files." Because, you know, it is bad to put users and passwords in /etc but sticking ssh keys there is just fine.

              --
              cats~$ sudo chown -R us /home/base
              • (Score: 2) by rleigh on Saturday May 02 2020, @08:09AM

                by rleigh (4887) on Saturday May 02 2020, @08:09AM (#989381) Homepage

                Debian (internally) uses a patched OpenSSH to store the public keys in LDAP. This avoids the need for a centrally mounted NFS home directory on every system. It also means the permitted keys are centrally managed and that key-only access to systems can be revoked in a single action. Maybe this has been picked up by the OpenSSH people now, but IIRC they used to be averse to this approach.

          • (Score: 2) by hendrikboom on Saturday May 02 2020, @02:38PM

            by hendrikboom (1125) Subscriber Badge on Saturday May 02 2020, @02:38PM (#989482) Homepage Journal

            That plug-in file system is encrypted?
            So why not let the login password for the visiting user be the passphrase for the decryption key?
            The encrypted filesystems I have demand a passphrase when I mount them.
            All we'd need is a change to the login process to enable the user to mount his home directory by passphrase.
            Or that could even be done by an automounter, that subsequently logs in the user plugging the encrypted file system in.

            seems simple.

            -- hendrik

        • (Score: 2) by janrinok on Saturday May 02 2020, @07:40AM

          by janrinok (52) Subscriber Badge on Saturday May 02 2020, @07:40AM (#989372) Journal
      • (Score: 0) by Anonymous Coward on Saturday May 02 2020, @08:26AM

        by Anonymous Coward on Saturday May 02 2020, @08:26AM (#989383)

        However, I absolutely do require that I can log into my account with SSH, which apparently is a no-go with this "solution".

        To be fair, this is not an entirely new problem with SSH. Similar problems occur when using NFS and Kerberos: unless you've previously authenticated (and your credentials have not expired), the ssh server cannot access the NFS filesystem and cannot authenticate against an authorized_keys file on such a filesystem. And even if it could read authorized_keys, you would end up with a session that couldn't initially access any files (may not be a huge problem but e.g., you wouldn't be able to rely on your shell startup scripts running all the time).

        One way to avoid this particular problem is to use GSSAPI authentication in SSH (instead of public key authentication). You can forward credentials from the connecting machine to the SSH server (GSSAPIDelegateCredentials option) and then those credentials enable access your files via NFS. Perhaps someting similar could be accomplished with encryption keys. Maybe you could even do such a thing with GSSAPI as it already exists.

    • (Score: 1) by DECbot on Friday May 01 2020, @03:58PM (7 children)

      by DECbot (832) on Friday May 01 2020, @03:58PM (#989011) Journal

      So, if the login information is in the encrypted partition, on a system you have never touched before how do you decrypt the drive? Does a pop-up show up over the login prompt asking you to decrypt the drive? So the system should automatically trust and attempt to decrypt all drives plugged into it? I'm asking because I've never looked into this beyond what the talking heads praise and blather about on ye-ol' podcasts.

      --
      cats~$ sudo chown -R us /home/base
      • (Score: 2) by janrinok on Friday May 01 2020, @05:50PM (6 children)

        by janrinok (52) Subscriber Badge on Friday May 01 2020, @05:50PM (#989075) Journal

        In exactly the same way that you decrypt a LUKS drive now. We've been using LUKS for many years. It works. All my hard drives are secured using it. You can type in a password or use something like 4kb of random data as the key and store it on a usb key.

        If you don't want your machines to have the facility to accept such a drive you simply disable the LUKS support for specific or all USB devices.

        • (Score: 1) by DECbot on Friday May 01 2020, @06:40PM (5 children)

          by DECbot (832) on Friday May 01 2020, @06:40PM (#989096) Journal

          Right, I'm using LUKS to encrypt my SSD on my ZFS on root laptop now. That gets decrypted on boot before booting into a kernel. My question is regards to the scenario where you have a portable drive with the LUKS encrypted home directory. I'm guessing the user's password file, the replacement for /etc/shadow, is unencrypted somewhere on that volume with the encrypted partition? Perhaps in a second partition? Or is the encrypted partition really just an LUKS encrypted file on an unencrypted partition with the user info the system can use authenticate against?
           
          And am I required to use LUKS or can I use the native ZFS encryption?

          --
          cats~$ sudo chown -R us /home/base
          • (Score: 2) by janrinok on Friday May 01 2020, @08:36PM (3 children)

            by janrinok (52) Subscriber Badge on Friday May 01 2020, @08:36PM (#989178) Journal

            OK, as i understand it:

            When you log in to your home directory the password is used to decrypt the LUKS encryption that has been applied automatically to the home directory contents. When you log out the home directory contents are securely encrypted again using LUKS. The encryption of the home directory is always LUKS, as this is the linux standard encryption.

            It is possible to have your home directory on a separate drive which can - but need not necessarily - be removable.

            If it is removable it is possible to use the same drive on different computers. The target computers must be configured to accept such drives and the configuration remains under the control of the administrators of the computers. Thus if someone doesn't want to give anybody the ability to insert a drive then he can configure the computer to simply ignore the drive when it is inserted, which might simply be a case of plugging it in via a USB cable. However, an administrator can configure the computer to accept such drives. I do not have any details of this process but the capability was discussed in various computer magazines over 6 months ago.

            It is also possible to encrypt an entire drive - which it appears that we both do. I do not know if any other encryption than LUKS can be used for this process which would still enable systemd.homed to function, but I doubt it. As systemd.homed has not yet been released I haven't got any experience of using it. I have read reports about the potential of the new systemd.homed and have seen the various git discussions regarding its development . It is not clear from what I have read whether a fully encrypted drive is first decrypted as it usually would be by the system and then the home directory is subsequently decrypted again when you log in, or whether the full disk encryption defeats the 'homed' function entirely. It is also possible that the earlier publicity was also speculative and could therefore be inaccurate.

            It is entirely possible that the drive remains in place inside a single computer but, as it is encrypted when the user logs out, even the administrator cannot get access to your private data. He will simply see an encrypted user area. It will not protect your data once you have logged in as root will still have access to your user partition if you are on a network, although other users could be controlled by the usual user/group permissions..

            The user data that is stored as JSON provides sufficient information to replicate your user id on whichever computer it is connected to providing that the administrator has configured the computer appropriately. It also - if I understand it correctly - manages to deconflict your userid from existing userids already on the computer. I do not know how it does this.

            • (Score: 3, Interesting) by Bot on Friday May 01 2020, @10:00PM (2 children)

              by Bot (3902) on Friday May 01 2020, @10:00PM (#989230) Journal

              What's missing from this scenario is that home directories contain machine-specific configuration files. Which means that the portable home will be screwed up when you take it back home. Hey why is all audio rerouted to one channel when my soundcard has 8? Hey why the window is outside the screen?

              Has poettering addressed these INSIGNIFICANT details?

              --
              Account abandoned.
              • (Score: 1, Insightful) by Anonymous Coward on Friday May 01 2020, @10:13PM (1 child)

                by Anonymous Coward on Friday May 01 2020, @10:13PM (#989235)

                Those are insignificant issues fixed by an if statement.

                • (Score: 2) by Bot on Sunday May 03 2020, @07:21PM

                  by Bot (3902) on Sunday May 03 2020, @07:21PM (#989869) Journal

                  It's trivial to split machine dependent prefs from document related prefs, but done on the whole of an ecosystem it is a tragedy. Where would you put that if statement? systemd? preference parsing code? transfer routines?

                  --
                  Account abandoned.
          • (Score: 0) by Anonymous Coward on Friday May 01 2020, @09:34PM

            by Anonymous Coward on Friday May 01 2020, @09:34PM (#989210)

            If you use the drive only in userland, ZFS native encryption is probably preferable. For anything that needs early mount, or other sw integration, you probably want LUKS.

  • (Score: 3, Insightful) by Bot on Friday May 01 2020, @01:35PM (3 children)

    by Bot (3902) on Friday May 01 2020, @01:35PM (#988937) Journal

    Good objection but, let's proceed in an orderly manner. Soon the limitation of json will become apparent and a new DSL will be needed to deal with the pesky problem of access to home dirs. Just have people onboard this for the moment, you want people to get entrapped first.

    --
    Account abandoned.
    • (Score: 2) by bzipitidoo on Friday May 01 2020, @07:15PM (2 children)

      by bzipitidoo (4388) on Friday May 01 2020, @07:15PM (#989120) Journal

      Limitations of JSON? What limitations are you talking about? That it isn't YAML?

      • (Score: 2, Touché) by DECbot on Friday May 01 2020, @07:27PM (1 child)

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

        It's not some sort of binary format only readable by some systemd utility.

        --
        cats~$ sudo chown -R us /home/base
        • (Score: 0) by Anonymous Coward on Saturday May 02 2020, @05:32AM

          by Anonymous Coward on Saturday May 02 2020, @05:32AM (#989346)

          In case you are wondering, they are actually working on a binary form of JSON. There are a couple, actually. But the one people seem to be settling on is UBJSON and its introduction has be suggested a few times to systemd.