Le 2015-05-26 12:58, Boudewijn Dijkstra a écrit :
Op Tue, 26 May 2015 11:07:06 +0200 schreef Simon
<openbsd.li...@whitewinterwolf.com>:
Le 2015-05-26 00:10, Miod Vallat a écrit :
It is not the responsibility of the operating system to protect its
users against software which assumes using the pid as a random source
is
a bright and wise idea.
Isn't this the whole goal of random PIDs, to put a defense at OS level
protecting software against themselves when they make wrong assumption
regarding the PID and use it for wrong purposes?
One can protect against programmers assuming sequential allocation and
one can protect against programmers assuming random allocation, but
not both.
Unless specific cases, I do not think that programmers assume that PID
are especially sequential or not, but merely rely on the hypothesis
that:
- PID are unguessable,
- PID will not be reused quickly.
And yes, it seems possible to fulfill these two properties by
providing unguessable and not quickly reusable PID instead of pure
random PID.
Moreover, would I have to choose between random PID adding a
protection against potential local exploits but opening potential
remote exploits, and sequential PID opening potential local exploits
but at least not causing remotely exploitable weaknesses, I would tend
to consider sequential PID more secure than pure random PID (as long
as one considers that remotely exploitable vulnerabilities have higher
severity than local ones).
Unguessable and not quickly reusable PID would be the third and most
secure option, providing protection both against local and remote
exploits (and keeping ports people hair (reference to Theo de Raadt
answer in the current thread) in a more reliable way than the 100
items array which is effectless in loaded environments).
