systemd implements ransomware for your own home directory

[ben_lubar]

@PJH said in WTF Bites:

@Zerosquare said in WTF Bites:

Do you use Linux?
Did you like pulseaudio and systemd?
Then you'll love Lennart Poettering's new groundbreaking idea:

Jack Wallen

Linux home directory management is about to undergo major change | TechRepublic

With systemd 245 comes systemd-homed. Along with that, Linux admins will have to change the way they manage users and users' home directories.

Two immediate thoughts, not entirely mutually exclusive:

• this was posted there 29 days too late.
• this deserves it's own thread, not a post in Bites

Once that user logs out, the home directory is automatically encrypted.

Oh dear - if you want some -xxxxxxr-- files in there, you need to be logged in 24x7. What do you mean multi-user systems don't exist, with http://example.com/~user not being a personal webpage from the '80's... (or other more cromulent reasons for wanting read-only stuff in ~, that other people should be able to read.)

I presume he's doing something weird and wonderful with ~/.ssh.

In fact I presume he's thought about it to begin with.

Yes?

<finishes reading the article..>

Oh - seriously, and honestly, I hadn't got this far in the article until I typed that aside:

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.

Should Poettering not be able to develop a solution for the SSH conundrum, systemd-homed will have to be relegated to desktops and laptop distributions, leaving servers out of the mix. I cannot imagine that will fly with the systemd team.

Excited for this to be enabled by default on Ubuntu or whatever and have this brick a bunch of servers

[ben_lubar]

So, for the simple act of logging in, three mechanisms are required (systemd, /etc/shadow, /etc/passwd). This is inefficient,

[PleegWat]

I get the impression that the systemd folks dream of a system which contains two processes - sytemd and the kernel.

[topspin]

@PleegWat said in systemd implements ransomware for your own home directory:

I get the impression that the systemd folks dream of a system which contains twoone processes - sytemd and the kernel.

Everything runs on systemd-chromed.

[dkf]

@PleegWat said in systemd implements ransomware for your own home directory:

I get the impression that the systemd folks dream of a system which contains two processes - sytemd and the kernel.

They're not so keen on the kernel either. Anyone for systemd-kerneld?

[dfdub]

@Gąska said in systemd implements ransomware for your own home directory:

There were like 150 identical servers provisioned, about 10 of which were assigned to our project (server assignment was changing over time). If one server had too much use, I just ssh'd to different one on the fly. If I had to setup a different .bashrc, .zshrc, SSH keys etc. on each of them, I'd go insane (I mean, more insane than now). Roaming profile was a lifesaver.

Well, that's why in any sane cluster setup, the home directories are on NFS.

[dfdub]

@ben_lubar said in systemd implements ransomware for your own home directory:

Excited for this to be enabled by default on Ubuntu or whatever and have this brick a bunch of servers

I don't think this will be enabled anywhere by default, except maybe on Fedora. It is designed to be an optional part of systemd, which the linked article fails to mention. It's also not meant to be used on servers AFAIK.

BTW: You can easily configure sshd to look for the autorized keys elsewhere: https://man.openbsd.org/sshd_config#AuthorizedKeysFile

[dkf]

@dfdub said in systemd implements ransomware for your own home directory:

Well, that's why in any sane cluster setup, the home directories are on NFS.

And the rest of the cluster is probably connected to the NFS system by a dedicated high-capacity network. You really don't want anything else to interfere with filesystem access.

[dkf]

@dfdub said in systemd implements ransomware for your own home directory:

You can easily configure sshd to look for the autorized keys elsewhere

All of which becomes fun on a system with multiple users, and which is why this is all such a stinking mess.

[dfdub]

@dkf said in systemd implements ransomware for your own home directory:

All of which becomes fun on a system with multiple users

If you read the man page carefully, you'll notice that this directive allows per-user authorized key files. It'd be pretty useless otherwise.

You can even generate the list programmatically: https://man.openbsd.org/sshd_config#AuthorizedKeysCommand
OpenSSH is pretty damn flexible.

Edit: The only problem would be that ssh-copy-id wouldn't work on such a system. You'd need a custom script.

[dkf]

@dfdub said in systemd implements ransomware for your own home directory:

If you read the man page carefully, you'll notice that this directive allows per-user authorized key files. It'd be pretty useless otherwise.

Yes, but then you still have to have somewhere that is writable by users for them to put their keys (without overwriting each others') and, because of the design of homed, you can't use the usual solution for this and put it in someone's home directory. For technical reasons, you can't make it so that users can only write a single file in the location (not and allow any form of self-service updates), so you instead need to have a whole directory there. So now you've got somewhere else user-writable that is holding user configuration files too. Totally not going to be trouble, that…

Or you make a system that is more locked down and where some asshole sysadmin can tell users that they may not change their ssh key. Because one capability effectively comes for free with the other (and experience with sub-human nature).

[dfdub]

@dkf said in systemd implements ransomware for your own home directory:

So now you've got somewhere else that is holding user configuration files too. Totally not going to be trouble, that…

We've had this problem since someone decided that the user's preferred shell should be stored in /etc/passwd. So sysadmins already have to give users a way to configure options stored outside /home. The only news is that they now need to add another field to the intranet application for configuring your Linux user that they already have. Iff they use systemd-homed, which nobody will do on servers anyway.

Or you make a system that is more locked down and where some asshole sysadmin can tell users that they may not change their ssh key.

You can already do that very easily, see the man page I linked above.

[error]

@topspin said in systemd implements ransomware for your own home directory:

@PleegWat said in systemd implements ransomware for your own home directory:

I get the impression that the systemd folks dream of a system which contains twoone processes - sytemd and the kernel.

Everything runs on systemd-chromed.

I am summoned, and so I appear.

---

Filed under: Off by Out of Context is

[dcon]

@topspin said in systemd implements ransomware for your own home directory:

Break early, break often?

Facebook integration complete.

[PleegWat]

@dkf said in systemd implements ransomware for your own home directory:

@dfdub said in systemd implements ransomware for your own home directory:

If you read the man page carefully, you'll notice that this directive allows per-user authorized key files. It'd be pretty useless otherwise.

Yes, but then you still have to have somewhere that is writable by users for them to put their keys (without overwriting each others') and, because of the design of homed, you can't use the usual solution for this and put it in someone's home directory. For technical reasons, you can't make it so that users can only write a single file in the location (not and allow any form of self-service updates), so you instead need to have a whole directory there. So now you've got somewhere else user-writable that is holding user configuration files too. Totally not going to be trouble, that…

Or you make a system that is more locked down and where some asshole sysadmin can tell users that they may not change their ssh key. Because one capability effectively comes for free with the other (and experience with sub-human nature).

You could do it like cron does it. Not saying you should, but you could.

[ben_lubar]

What does this actually do, though, apart from reinventing a wheel?

If the home directory is encrypted using a key that's available to the system, isn't that the exact same thing as just setting permissions?

systemd doesn't even handle auth right now - PAM does that as far as I know.

Are they saying that they want to put the home directory somewhere else? That's what /etc/passwd is for, one of the files they say they want to get rid of.

How does digitally signing the auth file help do anything other than provide another point for the system to break? If someone has the ability to modify the file, surely they also have access to the key, right?

[topspin]

@ben_lubar said in systemd implements ransomware for your own home directory:

What does this actually do, though, apart from reinventing a wheel?

You're not going to get very far with that attitude.

[Kamil Podlesak]

I haven't looked at the proposal itself, but everything I've read so far (in this discussion and the article) is one big heap of

There is absolutely no need to replace /etc/{passwd,group,shadow} files, because (mainstream) Linux already does have replacement mechanism called nss (Name Service Switch)! These files are not used directly, but via api which gets records from various sources configured in /etc/nssswitch.conf (if you look inside, you can see the the "files" provider is not even the only default value used). The same mechanism is used also for other less-known enumerations like /etc/services (basically port names) and for hostnames (quite important one is /etc/hosts + dns).

There are, of course, implementations for various centralized user managements, including windows domains.

I remember that nss was quite controversial 20 years ago, when conservatives said things like "I will not accept this crap in my slackware, ever - /etc/passwd was good for my grandfather and we have already got this newfangled /etc/shadow thing"

But "replacing /etc/passwd" in 2020?

[sh_code]

@dkf said in systemd implements ransomware for your own home directory:

And systemd linux being systemd linux, it'll never describe what the problem is in a way that allows anyone to figure out what the problem is; that user will just have to hope that they've got backups they can google the magic shell command that nobody understands but it seems to fix the issue because that home directory will be permanently lost otherwise that issue will be permanently unsolved.

FTFY ;)

[sloosecannon]

@Gąska

GitHub - sjennison/default-home-dir: My default home directory config

My default home directory config. Contribute to sjennison/default-home-dir development by creating an account on GitHub.

[JBert]

@sloosecannon Completely unrelated, but I find it interesting that your github onebox still show's the avatar hatted by @abarker whereas your WTDWTF one is the plain logo.

[Tsaukpaetra]

@JBert said in systemd implements ransomware for your own home directory:

@sloosecannon Completely unrelated, but I find it interesting that your github onebox still show's the avatar hatted by @abarker whereas your WTDWTF one is the plain logo.

Thanks for noticing that for me! I couldn't even tell at first...

[aitap]

@Kamil-Podlesak And here is an example of such a replacement that actually makes sense and works somewhere in production.

[JBert]

@Tsaukpaetra Oh, right, the "chat availibility" icons... Here's a screenshot from the light theme without those icons:

[sloosecannon]

@JBert said in systemd implements ransomware for your own home directory:

@sloosecannon Completely unrelated, but I find it interesting that your github onebox still show's the avatar hatted by @abarker whereas your WTDWTF one is the plain logo.

Wait how the fuck... when did that happen?

EDIT: Fixed. My avatar is now the correct one