Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacem...
Idk for the network stack, but for homed, I think it’s because it is up to the DEs to support it. As part of the Sovereign tech fund, GNOME is implementing support for it! I think this will be a great step forward for Linux desktop security when it lands
homed isn’t exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.
user-password based encryption of the home directory, so the password is required to unlock it (no admin access)
That seems like a very niche feature given that it is only relevant if the admin isn’t the same person as the user but the admin would have to set it up and condemn themselves to hearing endless whining from users who lose their files when they forgot their password.
SElinux is a “global ACL.” You can stop root from doing anything you like with it. Usually by accident and without realizing it’s been done in my experience…
No, that is just not true. You can stop root from doing things without a reboot with SELinux but encrypting something with a password root does not know actually does stop them from doing it at all short of a brute force attack on the encryption.
I don’t know, unless I personally allow the admin to have that kinda access to my files I wouldn’t really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.
As long as it’s not a mandatory switch, I can’t see any issue with this.
In theory it isn’t mandatory, in practice you will see a lot of distros replacing it.
You think? Hardly anyone uses the built-in network stack or the homed thing.
Idk for the network stack, but for homed, I think it’s because it is up to the DEs to support it. As part of the Sovereign tech fund, GNOME is implementing support for it! I think this will be a great step forward for Linux desktop security when it lands
It’s the same drama as with the home directory replacement they announced and that no-one ever used.
homedisn’t exactly a home directory replacement, more of an extension. You can mix and match homed and normal home directories like you want (on a per-user basis at least, not within a single user). It does have some nice things, such as user-password based encryption of the home directory, so the password is required to unlock it (no admin access) or automatically using subvolumes on btrfs.That seems like a very niche feature given that it is only relevant if the admin isn’t the same person as the user but the admin would have to set it up and condemn themselves to hearing endless whining from users who lose their files when they forgot their password.
Let me introduce you to selinux.
In what way does selinux allow your users to lock themselves out of their own home directories in a way that the admin can not fix?
SElinux is a “global ACL.” You can stop root from doing anything you like with it. Usually by accident and without realizing it’s been done in my experience…
No, that is just not true. You can stop root from doing things without a reboot with SELinux but encrypting something with a password root does not know actually does stop them from doing it at all short of a brute force attack on the encryption.
That’s true - you can often recover a bad ACL. I was thinking more of the “niche use case” where separating duties and restricting root are concerned.
no…nonono… AHHHHH! - Vegita DBZA
I don’t know, unless I personally allow the admin to have that kinda access to my files I wouldn’t really want it. And for that case you can enroll recovery keys (which would need to be manually stored, but still) or a fido token or whatever other supported mechanism there is, its LUKS2 backed encryption after all. Then there is also the possibility to just not encrypt the home directory at all.