[Secure-testing-team] Bug#763938: needrestart shouldn't checky only for daemons that need to be restarted

Christoph Anton Mitterer calestyo at scientia.net
Fri Oct 3 23:48:16 UTC 2014


Package: needrestart
Version: 1.2-1
Severity: important
Tags: security upstream


Hi.

Right now needrestart only tracks services/daemons.
This is of course a problem, less on systemd systems but even there.

Two simple arguments:
1) services are spawning processes which are not restarted via the
init script / unit file.
Best example is ssh, where the actual processes for the ssh sessions
are not restarted (in order not to terminate those connections).
And this behaviour is unlikely to change.

But what if a vulnerability was found in ssh, which not only affects
the listening process on port 22, but also the session processes?
These may run for a very long time or (e.g. with ssh control channel
multiplexing) run basically "forever".


2) Another example are any "normal" processes currently run by the
users Users could run their own sshd on non privileged ports (and all
this would happen in the cgroup of the user session) or they could
just execute vulnerable processes in the forground.



Now I guess the mainpurpose of needrestart is the security POV,
i.e. that people not only upgrade their stuff, but also restart it
when necessary.

But somehow I'd always expect to get a big list of processes, e.g.
when shellshock happened to bash, one should see a list of all bash
processes running, perhaps being sortable by user, maybe with a
functionality to email that user (e.g. taking data from passwd's
GECOS field[0]), or to write him with mesg(1).
Any maybe one could also have powerful selectors like:
- do nothing for a users's processes
- sigint them
- sigkill them


Cheesr,
Chris.

btw: I mark this important+security since I feel the main idea of
needrestart is to notify the admin about remaining security issues,
even though packages have been upgraded.
Since needrestart only notifies you about services/daemons I feel
that an important part of this job is not yet done.


[0] https://en.wikipedia.org/wiki/Gecos_field



More information about the Secure-testing-team mailing list