On Thu, 2 Jun 2016, Lennart Poettering wrote:
Well. Let's say you are responsible for the Linux desktops of a
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
This all has nothing to do with individual processes on machines. If
you are a big bank you better well detect rogue processes using up CPU
on your install base.
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.
No you don't. you are creating simplistic world views that are not
As others have said, the only simple case of killing processes is those
with no use when the user is gone - that is locally started windowing
applications. Really, we need to fix gnome and gdm and stuff that
lingers where the problem is. We don't need systemd to kill my 200
gdm lockscreen binaries that eventually run me out of resources to
unlock my screen. We need gdm to see its bugs and fix it.
This is really just one example. This model I think really needs to
the default everywhere.
People aren't agreeing with you. So making it a default seems like a bad
idea. People do seem to agree on "obviously broken windoing apps" that
are left lingering. Why can't we just let those get killed?
On desktops and on servers: unless the admin
permitted it explicitly, there should not be user code running.
no, user code may be running everywhere as long as it does not affect
the purpose or policies of the machines. Such policies are not written
by filenames of binary files.
allow your intern user access to a webserver to quickly check our the
resource consumption of some service that doesn't mean that he shall
be allowed to run stuff there forever, just because he once had the
login privilege for the server. And even more: after you disabled his
user account and logged him out, he really should be gone.
apart from your use case taking up 4 lines, which seems like a difficult
policy to code into applications (remember you would also need to be
able to code the reverse of that policy) the only thing I do agree with
you here is that unlisted uids/gids might be fair game to shoot. But one
has to wonder how well that works in the case of network outages where a
NIS server or something is temporarilly unavailable and you start
shooting legitimate processes.
Yes, UNIX is pretty much a swiss cheese: it's really hard to
system properly so that somebody who once had access won't have access
anymore at a later point. However, we need to start somewhere, and
actually defining a clear lifecycle is a good start.
But your definition is already running foul with just a handful of
software developers and it will cause large unexpected problems in the
For example, a decade ago at a najor airline, they had their core
database automatically deleted each night. turns out an overeager
cronjob deletes all "core" files that crashed applications left all
over the servers. To me, systemd shooting processes is not different.
If you are that concerned about processes, you need a strict security
policy on what proccesses you allow to be _started_, not trying to
fix your mistakes afterwards by shooting.