Lennart Poettering writes:
Well. Let's say you are responsible for the Linux desktops of a
large
security-senstive company (let's say bank, whatever), and the desktops
are installed as fixed workstations, which different employees using
them at different times. They log in, they do some "important company
stuff", and then they log out again. Now, it's a large company, so it
doesn't have the closest control on every single employee, and
sometimes employees leave the company. Sometimes even the employees
browse to the wrong web sites, catch a browser exploit and suddenly
start runing spam bots under their user identity, without even
knowing.
In all of these cases you really want to make sure that whatever the
user did ends – really ends – by the time he logs out. So that the
Nice theory. But there's a problem with this proposal.
If an unprivileged program, like tmux, or screen, or nohup, can do whatever
dbus/ibus thingy it needs to do in order to elevate itself to a new
"session", and make arrangements to prevent itself from getting nuked from
high orbit by KillUserProcesses, then the same thing can obviously be done
by any other process. Like the same rogue spambot that's being discussed
here. The rogue spambout in question can simply talk to systemd itself, and
arrange for it not to be killed when the user logs out. Just like any other
process. There goes the added "security" we were hoping to achieve, here.
This KillUserProcesses feature offers no real "security" benefit here
whatsoever. I am confident that any professional, who's actually making some
bread in information security, will reach this conclusion without taking
much time; just a brief, cursory analysis. The claim that KillUserProcesses
implements any kind of system security is quite funny. And this doesn't
exactly give me a warm and fuzzy feeling – who knows what other things that
are also thought to be enforcing system security are lurking inside the
systemd monolith…
Anyway, in order for this to be truly effective security, it should not be
possible for any ordinary process, like tmux, screen, or nohup, without them
being privileged binaries in some way (either via s[gu]id, capabilities(7),
or selinux)[*].
Well, good luck with that.
[*] Not 100% true, actually. There are ways to come up with fairly bullet-
proof framework for privileged processes on Linux, without relying on system-
level support like suid/capabilities/selinux, but this is veering more off-
topic than this already is.