4 ms·

There's a problem with loading the home directory as a loopback block device from roaming USB disks - untrusted filesystems aren't safe to mount. From https://

by mappu 7y ago

There's a problem with loading the home directory as a loopback block device from roaming USB disks - untrusted filesystems aren't safe to mount. From https://lwn.net/Articles/755593/ https://lwn.net/Articles/755593/ "Unprivileged filesystem mounts, 2018 edition": > There's little we can do to prevent people from exploiting flaws in the filesystem's on-disk format. No filesystem has robust, exhaustive verification of all it's metadata, nor is that something we can really check at runtime due to the complexity and overhead of runtime checking. [...] "Go run your filesystem in userspace with fuse if you want stronger security guarantees." But the same topic is also discussed in many similar articles, e.g. more recently regarding the likeliness of opening new bugs for everyone using automount since the new EROFS filesystem has been merged into the mainline kernel.

poettering 7y ago
Yes this is a problem. To address this systemd-homed is careful to validate the user record enclosed in the volume first (which includes checking its signature against the keyring of accepted record signers) and checks whether the provided user password can unlock it. Only after this validation and that the fs actually matches the record we will mount it. Thus as long as the employer trusts its employees enough things should be reasonably safe. (To make this happen the user record is embedded into the LUKS2 header metadata so that we can use it before mounting the fs)
- Mrat 7y ago
  Hi, Lennart. My question isn't related to what you were answering in this comment but it's related to some problems I have to deal since I'm constantly moving my /home folder from a distribution to another. I always have to delete files like ~/.local/share/applications/.desktop because otherwise it will show stuff that shouldn't be available in a freshly-installed distribution and it makes me think it's "contaminated"*. I wanted to know how this new implementation deals with those cases. BTW, congratulations! You made a systemd "hater" like me agree with you. I would be really grateful if this solution made me forget about cleaning up my home before a new install. Have a nice day!

by mappu 7y ago

poettering 7y ago

Yes this is a problem. To address this systemd-homed is careful to validate the user record enclosed in the volume first (which includes checking its signature against the keyring of accepted record signers) and checks whether the provided user password can unlock it. Only after this validation and that the fs actually matches the record we will mount it. Thus as long as the employer trusts its employees enough things should be reasonably safe. (To make this happen the user record is embedded into the LUKS2 header metadata so that we can use it before mounting the fs)

Mrat 7y ago
Hi, Lennart. My question isn't related to what you were answering in this comment but it's related to some problems I have to deal since I'm constantly moving my /home folder from a distribution to another. I always have to delete files like ~/.local/share/applications/.desktop because otherwise it will show stuff that shouldn't be available in a freshly-installed distribution and it makes me think it's "contaminated"*. I wanted to know how this new implementation deals with those cases. BTW, congratulations! You made a systemd "hater" like me agree with you. I would be really grateful if this solution made me forget about cleaning up my home before a new install. Have a nice day!