6 ms·

Keep in mind the main use case for this is local desktop/interactive sessions. For system/service accounts, you can still use regular passwd files, SSH auth et

Keep in mind the main use case for this is local desktop/interactive sessions. For system/service accounts, you can still use regular passwd files, SSH auth etc. As you eluded to, the problems this is trying to solve include better integration/less rough edges with enterprise authentication (AD and the like), encrypting home directories, and making home directories and user accounts more portable. Anyone that does desktop fleet management will find a lot of stuff to be excited about here.

jasonjayr 7y ago
I know the video had limited times, but in regards to enterprise authentication, is there any consideration to data ownership? In this scheme can the enterprise, or any superior device/data owner have a master key to decrypt home directory of a subordinate user?
- candiddevmike 7y ago
  I do not believe so. The homectl docs state that the encryption password == user password without any alternative: https://www.freedesktop.org/software/systemd/man/homectl.html https://www.freedesktop.org/software/systemd/man/homectl.htm...
  - jasonjayr 7y ago
    Thanks for that link. I see further down that PKCS#11 is supported: > Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV smartcard) that shall be able to unlock the user account. The security token URI should reference a security token with exactly one pair of X.509 certificate and private key. A random secret key is then generated, encrypted with the public key of the X.509 certificate, and stored as part of the user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the account and associated resources. See below for an example how to set up authentication with security token. Key hierarchy management can probably be delegated to an external system.
  - nullc 7y ago
    FWIW, if you want to do dynamic mounted encrypted home you can do so today with pam_mount pretty easily. The two passwords can even disagree, you'll just get prompted twice during the login process. In fedora, at least, it requires only three lines of configuration changes (adding the pam hooks, and setting up the mount point in the pam_mount config).
  - throw0101a 7y ago
    > encryption password == user password What if your password is in LDAP, and you change it the OpenLDAP back-end? Or if you have OpenLDAP talk to AD (via SASL) for password checks, but the rest of the GECOS & group is in LDAP? Is Kerberos covered? How is NFS handled? Automounts? Doing a ^F I find no mention in the man page of either LDAP or Kerberos.
nullc 7y ago
You don't ever remotely log into your desktop??! What do you do if you've left files on your desktop at home/work and need them from work/home?
- candiddevmike 7y ago
  In theory with homed you can just keep all of those files (home directory) on a share or USB drive and access them anywhere. Im personally curious to see how this works with a tool like Syncthing
  - nullc 7y ago
    gee great, more unnecessary shoving everything into the "cloud"-- just to make sure that users have absolutely no due process protection for the confidentiality of their data. Microsoft and Google do this because they make money out of monetizing their users. What's systemd's excuse? As far as USB goes-- can you suggest a currently manufactured _good_ usb storage device? I've found myself scrounging for old ones because anything currently made are unreliable, slow (in spite of amazing performance claims), or usually both.
    - ta999999171 7y ago
      > Microsoft and Google do this because they make money out of monetizing their users. What's systemd's excuse? Who do you think is putting the resources (manhours/money/etc) into mainlining this crap into Linux? It's the corps. Add Intel to the list.
    - viraptor 7y ago
      > gee great, more unnecessary shoving everything into the "cloud"-- just to make sure that users have absolutely no due process protection for the confidentiality of their data. This doesn't really make sense as a response to comment mentioning Syncthing which works with any backend, including your other machines. > What's systemd's excuse? Systemd's excuse for what exactly?
      - 7y ago

jasonjayr 7y ago

I know the video had limited times, but in regards to enterprise authentication, is there any consideration to data ownership? In this scheme can the enterprise, or any superior device/data owner have a master key to decrypt home directory of a subordinate user?

candiddevmike 7y ago
I do not believe so. The homectl docs state that the encryption password == user password without any alternative: https://www.freedesktop.org/software/systemd/man/homectl.html https://www.freedesktop.org/software/systemd/man/homectl.htm...
- jasonjayr 7y ago
  Thanks for that link. I see further down that PKCS#11 is supported: > Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV smartcard) that shall be able to unlock the user account. The security token URI should reference a security token with exactly one pair of X.509 certificate and private key. A random secret key is then generated, encrypted with the public key of the X.509 certificate, and stored as part of the user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the account and associated resources. See below for an example how to set up authentication with security token. Key hierarchy management can probably be delegated to an external system.
- nullc 7y ago
  FWIW, if you want to do dynamic mounted encrypted home you can do so today with pam_mount pretty easily. The two passwords can even disagree, you'll just get prompted twice during the login process. In fedora, at least, it requires only three lines of configuration changes (adding the pam hooks, and setting up the mount point in the pam_mount config).
- throw0101a 7y ago
  > encryption password == user password What if your password is in LDAP, and you change it the OpenLDAP back-end? Or if you have OpenLDAP talk to AD (via SASL) for password checks, but the rest of the GECOS & group is in LDAP? Is Kerberos covered? How is NFS handled? Automounts? Doing a ^F I find no mention in the man page of either LDAP or Kerberos.

nullc 7y ago

You don't ever remotely log into your desktop??! What do you do if you've left files on your desktop at home/work and need them from work/home?

candiddevmike 7y ago
In theory with homed you can just keep all of those files (home directory) on a share or USB drive and access them anywhere. Im personally curious to see how this works with a tool like Syncthing
- nullc 7y ago
  gee great, more unnecessary shoving everything into the "cloud"-- just to make sure that users have absolutely no due process protection for the confidentiality of their data. Microsoft and Google do this because they make money out of monetizing their users. What's systemd's excuse? As far as USB goes-- can you suggest a currently manufactured _good_ usb storage device? I've found myself scrounging for old ones because anything currently made are unreliable, slow (in spite of amazing performance claims), or usually both.
  - ta999999171 7y ago
    > Microsoft and Google do this because they make money out of monetizing their users. What's systemd's excuse? Who do you think is putting the resources (manhours/money/etc) into mainlining this crap into Linux? It's the corps. Add Intel to the list.
  - viraptor 7y ago
    > gee great, more unnecessary shoving everything into the "cloud"-- just to make sure that users have absolutely no due process protection for the confidentiality of their data. This doesn't really make sense as a response to comment mentioning Syncthing which works with any backend, including your other machines. > What's systemd's excuse? Systemd's excuse for what exactly?
    - 7y ago