Lennart Poettering writes:
On Thu, 02.06.16 18:00, Sam Varshavchik (mrsam(a)courier-mta.com)
> 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
> 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,
Key here is that the life-cycle is enforced by privileged code, and
that this privileged code checks system policy (as in PolicyKit) when
deciding what to do. Yes, the default policy we ship is friendly, and
says that users can stick around if they want, via lingering, but key
here is that this policy check is done by privileged code, and stored
in privileged policy.
That's not the issue. As I wrote, "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,
So, this is "enforced by privileged code". That's wonderful news, but as
Benny Hill would say: biiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiig deal.
Unless it's possible to have KillUserProcesses mandatory for a given
userid's processes, and:
1) It is possible to have, say, tmux, make whatever arrangements are
necessary to prevent itself from getting killed, but
2) Make it impossible for any other random process, running under the same
uid, to do the same
only if these two conditions are met, then KillUserProcesses becomes an
effective security measure.
KillUserProcesses enforces some kind of security only if it is mandatory,
and perhaps with exceptions for approved processes. Which is not possible
without having a privilege escalation occur at some point in the execution
chain for those approved processes. This is POSIX Security Model 101.
But if, as it's being proposed, the option on the table is to make
KillUserProcesses optional, i.e. make it optional, even turned on by
default, but make it possible for a process to request itself to be lingered
past logout, and use this for tmux/screen/nohup, then this offers absolutely
no added security whatsoever. Becaus if tmux/screen/nohup can do it, then so
can any other process.
It can certainly be a useful feature perhaps, in many situations. But it
will not stop a rogue process that wants to linger. KillUserProcesses in its
proposed optional enabling in Fedora is not a security measure.