Distributors ponder a systemd change [LWN.net]

Distributors ponder a systemd change

Posted Jun 8, 2016 1:06 UTC (Wed) by smoogen (subscriber, #97) [Link] (1 responses)

But does it? You have to block cron, at, system level containers, and all their ilk to actually make sure that a service doesn't fire up after a user logs in. And in the primary work case where you have a user able to log in remotely, they also need to be able to use these sorts of system level services so it doesn't stop their setting up a reverse nc shell or stop someone from piggybacking on the ssh multiplex and making sure the account never truly logs out.

I understand the security item that Lennart sees, but I think that this is a bandaid where the 'fix' he wants will require him to write his own distribution from the 'ground-up' and find the users and use cases to use it. He gets angry about the amount of band-aids he is already carrying around, but this is in many ways the fact that the users already have too many of the old around and can not just fork lift fix their infrastructure at his urging.

Distributors ponder a systemd change

Posted Jun 16, 2016 16:18 UTC (Thu) by Wol (subscriber, #4433) [Link]

> He gets angry about the amount of band-aids he is already carrying around, but this is in many ways the fact that the users already have too many of the old around and can not just fork lift fix their infrastructure at his urging.

The problem is that your "band-aid" is Lennart's security hole. All these band aids are unnecessary code, that is more likely than average to harbour bugs (and hide bugs in the other program too), and are dangerous things to leave lying around. And this example is classic - leaving processes lying around because the system can't/won't get rid of them by default is exactly that! If they're buggy enough not to shut down, how many other bugs do they harbour?

Cheers,
Wol

Distributors ponder a systemd change

Posted Jun 8, 2016 1:42 UTC (Wed) by dskoll (subscriber, #1630) [Link] (3 responses)

The security issue is a red herring. If you want to make sure that all of a user's processes have been terminated, you use pkill -U and pkill -u. Distros could even make their user-deletion tools ask if you want to do this and then do it for you if you say yes.

Distributors ponder a systemd change

Posted Jun 8, 2016 2:23 UTC (Wed) by hmh (subscriber, #3838) [Link] (2 responses)

Even that is too little. You also need to ensure no changes were left that could allow such users to have access to something they shouldn't have -- unless you are actually purging the user from the system ("userdel" style).

I seem to recall a full fix for the "desktop" *security* case requires something like a revoke() syscall, and a proper SAK implementation. I hope I am wrong, because those can be quite hard to implement.

I mean, what is the point of killing every job started in an user session in the name of security, when all the user has to do is to simulate a login screen without ending his session at all in the first place?

There are other ways to ensure no desktop environment components are left behind when the session is closed, especially because these are actually a bounded set *and* because there would be little reason for them to refuse the patches.

Distributors ponder a systemd change

Posted Jun 8, 2016 8:27 UTC (Wed) by NAR (subscriber, #1313) [Link]

unless you are actually purging the user from the system ("userdel" style).

Well, if I want a user gone from the system, I'd want to do a decent job and purge it. Remove user id, cron jobs, all files, kill all processes, whatnot. I admit it might be complicated in a corporate multi-computer system when a user can have access to dozens of computers with some kind of single sign on - but systemd wouldn't help with the cronjobs either. Malicious users can also easily avoid the systemd reaping procedure. So I do think that the "security" issue is totally BS.

Distributors ponder a systemd change

Posted Jun 8, 2016 12:03 UTC (Wed) by dskoll (subscriber, #1630) [Link]

Even that is too little.

Yes, I know, but it is the equivalent (actually, a superset of) what systemd does when it kills processes started in the login session.

Distributors ponder a systemd change

Posted Jun 8, 2016 2:08 UTC (Wed) by Nahor (subscriber, #51583) [Link] (8 responses)

If the server runs under the user's id, it's easy to find.
If the server runs under its own account, then it doesn't matter if the user is logged in or not. The user could start it while staying logged in, then pretend nothing nefarious is happening (ssh is idle, terminal is idle, ...) while doing his evil things using the server.

To me, it seems that if you can't trust your users while they are logged out, you should be trusted them while there are logged in.

Moreover, there is still the "systemd-run" function to do the same thing as nohup/screen/... so it's not that they are removing the feature anyway, it's just used differently.

Distributors ponder a systemd change

Posted Jun 8, 2016 4:34 UTC (Wed) by rahvin (guest, #16953) [Link] (7 responses)

You're simplifying the problem. A zombie user process is a threat precisely because no one is actually in control of it making it available for anyone to potentially exploit with the user that started it no longer monitoring it. You don't have to distrust your users for that to be a security issue. I can think of hundreds of ways that could be bad even with a completely trusted user because everyone makes mistakes, zero day exploits exist, and zombie processes are an avenue for all kinds of mischief.

What if you had an orphaned ssl process when the heartbleed vulnerability was disclosed? Even if you patch the binary if you don't shutdown the zombies you just exposed your key to the world. IMO this is a good change to enable default security but I also totally agree that this should have been talked about very publicly that they were going to turn it on with X release. By not doing this they sabotaged their own effort because all the distributions will just disable it and boom it will never get implemented as default. And these programs like tmux and screen whose primary purpose is to daemonize a process (and have been around for more than 30 years) should have not only been warned but the systemd developers should have found a good way to retain that functionality that wouldn't require a dependency (in an upstream that's agnostic to the OS) to fix, even if that is a default exception for those specific binaries.

tldr It's a good change but it was handled terribly.

Distributors ponder a systemd change

Posted Jun 8, 2016 4:41 UTC (Wed) by drag (guest, #31333) [Link] (4 responses)

A zombie process is one that is killed and is waiting for the parent to reap it's return code.

There is no threat from them. They are not running anymore. They may be using up some memory in a process table or something, but that is about it. All it really means is that if you end up with a bunch of zombie processes you have a bug in the kernel or init or something.

Distributors ponder a systemd change

Posted Jun 8, 2016 8:57 UTC (Wed) by sbakker (subscriber, #58443) [Link] (3 responses)

I suspect rahvin meant "orphaned" rather than "zombie". Nevertheless, the term "zombie" is confusing, implying that the entity is somehow still active. It isn't. In fact:

“This process is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late process. It's a stiff. Bereft of life, it rests in peace. If its parent had reaped its exit status, it wouldn't be occupying a process slot, but pushing up the daisies instead. It's rung down the curtain and joined the choir invisible. This is an ex-process.”

A better name for zombie processes would be "corpse" or "carcass", but that just looks wrong in "top" listings. "Dead parrot" has a nice ring to it though.. :-)

Tasks: 304 total,   1 running, 303 sleeping,   0 stopped,   0 dead_parrot

Distributors ponder a systemd change

Posted Jun 8, 2016 15:44 UTC (Wed) by drag (guest, #31333) [Link] (2 responses)

Yes, I figured we might as well be consistent in what we are talking about here. Zombie is a very commonly used term.

A 'orphaned' process is essentially a daemon.

The problems we are running into now is that in Unix-ville every application was tied to a TTY. The 'getty' process was the 'session manager'. However it's complete shit to work in a modern environment by 'backgrounding processes'. So using daemons for setting up user environments and such things are very common. So is using terminal multiplexers like tmux or screen.

These are really just bandages to a bigger issue. All these things are just work arounds to the 'tty' limitations. As a result it's a big mess. You can control when you start up all these processes, but they are no longer tied to anything. You have to have some process to come back in when you log out to clean them up.

With systemd we now have the ability to have a true user session that is no longer tied to a particular tty. Systemd can 'daemonize' processes without actually going through the traditional deamonizing processes. It makes sense that when the user session dies so does their programs. It's just the way things should of always worked.

Distributors ponder a systemd change

Posted Jun 8, 2016 21:02 UTC (Wed) by rahvin (guest, #16953) [Link] (1 responses)

I did mean orphaned. I had one of those moments where I couldn't think of the right word so I used a different one.

I completely agree this is a needed change. The problem is it breaks 30 years of experience, and those types of breaks need lots and lots of warning or people will put workarounds in place that negate the change. Every distribution disabled it, IMO that's a sign they handled the messaging wrong.

Distributors ponder a systemd change

Posted Jun 8, 2016 23:35 UTC (Wed) by johannbg (guest, #65743) [Link]

"IMO that's a sign they handled the messaging wrong."

If by "they" you mean downstream distribution package maintainers of systemd you might be right depending on which community you reside in.

If by "they" you mean the upstream systemd community, it follow standard announcement procedure like most project do and that even got picked up and announce here on lwn [1].

Unlike many upstream project there is also always last call [2] open for couple of days before each upcoming release ( encase someone might have missed something or wants to discuss some change before release ) and for some facts ( since some people might find those relevant ) the change was committed in early april and it was Zbyszek that was pushing for this change not Lennart ( but apparently the pattern is blame Lennart or Gnome for all the world problems ).

1. https://lwn.net/Articles/688640/
2. https://lists.freedesktop.org/archives/systemd-devel/2016...

Distributors ponder a systemd change

Posted Jun 8, 2016 12:03 UTC (Wed) by itvirta (guest, #49997) [Link]

> What if you had an orphaned ssl process when the heartbleed vulnerability was disclosed?
> Even if you patch the binary if you don't shutdown the [running processes] you just exposed your key to the world.

That's a problem with all binary / library upgrades (libc and static binaries too). You need a way to find if a process is still using the old binary, and for long-running services
that needs to be done during the upgrade, not during some arbitrary point in the future, like someone's logout.

Distributors ponder a systemd change

Posted Jun 8, 2016 16:07 UTC (Wed) by Nahor (subscriber, #51583) [Link]

You misunderstand my question. My question is not about why it's dangerous to keep an orphaned process running but why it's *more* dangerous than a non-orphaned process. Why is it risky to keep a process running while logged out but it would be acceptable to keep that same process running with a user logged in 24/7?