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.
pgpp7BkIe9DNM.pgp
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
