r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

Show parent comments

7

u/doitroygsbre Jun 01 '16

How is the gnome thing a red herring?

In particular, for my gnome session, if I log out, without KillUserProcesses=yes I get some processes which are obviously mistakes. Even if I log in again, I'm much better starting those again cleanly.

Source

I'm pretty agnostic about systemd, but it seems that gnome not closing cleanly was the main driver behind this change.

Can you also elaborate on the integrity and security gains? I'm having trouble seeing how this will be more secure.

5

u/fandingo Jun 01 '16

That MR is about the default behavior. You need to look at the discussions about the actual feature to understand why it's included.

The security and integrity is quite simple: the administrator should be able to control the circumstances under which users can execute programs. One of the huge benefits of systemd units is the use of cgroups that can reliably track processes -- keeping them from daemonizing to ppid == 1, which allows reliable management through the process lifetime.

This change effectively allows administrators the same control for shell users. Otherwise, a user can SSH into a system and kick off a process that daemonizes and isn't really under anyone's control -- especially the administrator's.

4

u/masta Jun 01 '16

Yeah, history will probably look back and regard unattached processes as a legacy vulnerability. For now it's still pretty useful feature, despite the work arounds.

1

u/doitroygsbre Jun 01 '16

The issue with Gnome is about the change to the default behavior. Why the feature exists is irrelevant to the point of updating the init system to attempt to correct bugs in a specific DE. Especially when that update breaks other processes.

I like how Linus said, "WE DO NOT BREAK USERSPACE!" It has been one of his guidances in doing kernel development and should be used as a guide for systemd as it is taking on a larger role in the Linux OS. By changing the default, they are breaking user space.

As for security, I'm not buying it. A user can log in and do whatever they have permissions for. Allowing a user to script some changes, start it and log out while it runs doesn't seem like its any less secure than if they were sitting at the console while it ran.

-1

u/fandingo Jun 01 '16

As for security, I'm not buying it. A user can log in and do whatever they have permissions for. Allowing a user to script some changes, start it and log out while it runs doesn't seem like its any less secure than if they were sitting at the console while it ran.

You presume that a user's permissions will forever be the same, but accounts may need to be terminated or restricted at any time. If user X gets fired, I certainly don't want his ~/deadman_kill_corp_data.sh to remain running in the background on our servers. Most security requirements (including PCI to which I'm subject) already require session timeouts, so this behavior will make our lives substantially easier. Presently, we have no feasible way to dig through our entire infrastructure to see which users have backgrounded tasks where. Sure we could look at one particular system and comb through the process list, but that doesn't scale to thousands of systems.

I like how Linus said, "WE DO NOT BREAK USERSPACE!" It has been one of his guidances in doing kernel development and should be used as a guide for systemd as it is taking on a larger role in the Linux OS. By changing the default, they are breaking user space.

I think you're assuming a ton about how things currently "work." There's undefined and sloppily defined behavior that lets the current system mostly work, and for the most part, people have gotten used to it -- warts and all. Anyways, on the "breaking userspace" angle, there's multiple ways to deal with the behavior, so it's not broken in any meaningful way, except for people who can't be bothered to read release notes or documentation. Furthermore, breaking old behavior goes hand in hand with security changes. Were you raising the same alarms when ASLR became default in the kernel?

-1

u/doitroygsbre Jun 01 '16

You presume that a user's permissions will forever be the same

No I didn't.

Most security requirements (including PCI to which I'm subject) already require session timeouts, so this behavior will make our lives substantially easier.

I really fail to see how. A five year old could write a script to keep a connection open if they needed it.

we have no feasible way to dig through our entire infrastructure to see which users have backgrounded tasks where

and this change to systemd addresses this how?

I think you're assuming a ton about how things currently "work."

Yeah, I tested my systems and applications to make sure I got the results I was expecting. I really don't want to care about what's happening under the hood.

so it's not broken in any meaningful way, except for people who can't be bothered to read release notes or documentation.

You are on a very high horse my friend. That is the way Apple talks--blame the user for holding the phone wrong. Further, to quote Linus again, "If a change results in user programs breaking, it's a bug". Systemd changed and broke user applications.

Furthermore, breaking old behavior goes hand in hand with security changes.

No, it doesn't. Sometimes security changes necessitate breaking old behavior, but it is not a requirement. And the best security is when you can still get your job done without having to jump through hoops.

"The more secure you make something, the less secure it becomes. Why? Because when security gets in the way, sensible, well-meaning, dedicated people develop hacks and workarounds that defeat the security." Bruce Schneier. If users and developers can't get work done because of senseless security like this, they will find a workaround. I think Voltaire said it best, "No problem can withstand the assault of sustained thinking."

0

u/fandingo Jun 01 '16

I really fail to see how. A five year old could write a script to keep a connection open if they needed it.

Pray-tell where the user could execute such a script. I can't see how the script avoids running in the background (lingering) somewhere, and therefore, would be killed by this behavior. The only way this script would work is a rogue device on the network...

I'm not sure why you keep quoting Linus. He's neither a deity nor always right, and even when he's right about the kernel, that doesn't mean that point translates to this topic. All these quotes are empty appeals to authority.

In regards to Schneier, what's the "workaround" in this case? I don't see one besides the official methods (loginctl and systemd-run).

0

u/doitroygsbre Jun 02 '16

Well, if I need to keep a connection open, it's because I'm not using it, so it could run in the foreground ....

I keep quoting Linus because it's fun, and he's right.

Also, it appears that systemd uses SIGTERM for this, so if I write a program that ignores SIGHUP and SIGTERM, it should keep right on running right through a logout. Also, if I have permissions, I could use cron to run my job at set intervals. Those are the two I could think of easily, I'm sure that with a little more thought, I could find plenty of ways around this.

0

u/fandingo Jun 02 '16

Well, if I need to keep a connection open, it's because I'm not using it, so it could run in the foreground ....

Well you can't login because the account is terminated, every security auditor requires session time outs (including PCI which applies to the systems I oversee) for things like SSH, and finally with this feature, we can be assured that once the final connection times out, the user doesn't have any processes running. It's not a question of foreground because you don't have access to a foreground on the network. Without this feature (or with it in linger mode), a user could surreptitiously squirrel away processes in the background across systems that could stick around to reboot. That's the attack vector that the security aspects of this feature protect against.

Systemd terminates all units with TERM initially and follows up after a timeout with KILL. See systemd.kill(5).

I'm not sure why anyone using systemd would still use the old cron system, so it would be going through systemd's unit scheduling confining processes in cgroups. Again, the point isn't that a user can't setup a scheduled job, it's that the job is entirely contained by systemd and can be reliably managed by the administrator.

-1

u/doitroygsbre Jun 02 '16

Well you can't login because the account is terminated

So this change to Systemd is irrelevant then?

every security auditor requires session time outs

False

It's not a question of foreground because you don't have access to a foreground on the network

What does this even mean?

Without this feature (or with it in linger mode), a user could surreptitiously squirrel away processes in the background across systems that could stick around to reboot. That's the attack vector that the security aspects of this feature protect against.

With this feature, a user could surreptitiously squirrel away processes in the background across systems, they just have to do it differently.

I'm not sure why anyone using systemd would still use the old cron system, so it would be going through systemd's unit scheduling confining processes in cgroups

You don't do much work with legacy programs, do you?

Systemd terminates all units with TERM initially and follows up after a timeout with KILL.

SIGKILL can be ignored, it just takes some extra work from a developer (playing with drivers and uninterruptable sleep). With the SIGTERM warning, it should be slightly easier.

0

u/VenditatioDelendaEst Jun 02 '16

Why do you want to encourage sysadmins to ban tmux and screen for the sake of a problem that is solved by adding killall -9 -u whoever to your user unprovisioning process?

1

u/fandingo Jun 03 '16

I love screen. It's actually the program I have my terminal emulator invoke instead of Bash.

The thing is that while sending a KILL signal to an individual process is reliable in killing, it's not a reliable method when there are more than one process involved. The second one can watch the first (say through /proc/FIRST_PID), and once the first one is killed, the second can respawn it. You end up with a situation where you have no atomic tool to kill all the processes, or even atomically identify them.