4 ms·
Well, modern Android devices for one - they support multiple users, including quest accounts. So I guess they could use this instead of their (likely horrendous
by m4rtink 7y ago
Well, modern Android devices for one - they support multiple users, including quest accounts. So I guess they could use this instead of their (likely horrendous as it's Android) implementation.
Still, the main aim of this is in my opinion not safe isolation of users on a single machine, but rather safe locking of the encrypted root folder.
With a normal LUKS setup, everything is inside a LUKS container, including the rootfs from which the OS itself is running. This complicates locking the LUKS container when the device gets suspended, as there will be open files, etc.
With Homed as far as I can tell, this is explicitly possible, it should be able to drop the encryption keys when machine goes to suspend, making it less likely your data will be recovered if the machine gets lost or stolen. With the keys in RAM an attacker might attempt to pull it from the machine & read the keys or use some method to defeat the lockscreen. With the keys dumped from RAM, this is no longer possible.
- knorker 7y agoAndroid is so hugely different that it's not really an argument for adding it to systemd. > [locking when suspenden] With Homed as far as I can tell, this is explicitly possible Is it? Your home dir definitely will have open files when you lock or suspend.
- michaelmrose 7y ago> The go-luks-suspend program replaces the default suspend mechanism of systemd. It chroots to initramfs in order to perform the luksSuspend, suspend to RAM, and luksResume operations. It relies on the shutdown initcpio hook to provide access to the initramfs. https://github.com/guns/go-luks-suspend https://github.com/guns/go-luks-suspend from 2013 This also doesn't accidentally leak all the stuff not within /home/you