Lennart Poettering writes:
On Thu, 02.06.16 18:00, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) 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 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. 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, rogue spambot".
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.
Attachment:
pgptm1qopv5Sn.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
