[grsec] pid randomization problem - process won't execute and will return zero value

[John Logsdon]

Mmm

Something is very odd here and I don't think it is a grsec thing.  I am
still waiting for a clash on my twin Xeon-based (2.4GHz with HT enabled)
box after about 3 hours.  All it seems to do is for bash to take about 28%
of the processors, spread across all 4 with one processor taking about
10-11% and the other 3 taking the balance.

When generating a new pid, there must be a check that the new pid is not
already allocated as processes can cycle round.  Eventually, if this check
is not in place, even init will get overwritten with disastrous results
and on a busy system, such cycles will take place a number of times a day
or even an hour.  Of course if Linux were to abandon the legacy Unix
signed 16 bit integer for pids this would be a much rarer event but would
happen all the same.

Since the process asking for the new pid is also already allocated, this
check should ensure that randomised pids or ordinary pids should not
generate consequtive pids that are the same - or the same as any othe
already-existing pid.

The efficient way to do this is to generate a pid then check it.  If there
are say 200 process live, this will result in a re-sample only about in
only 200 out of 32768 cases (plus (200/32768)^2 etc to be pedantic).  
Such an approach is robust against any next-pid generating mechanism.

So unless the current pid is killed before generating the new pid, I
cannot see how this can happen or be due to grsec.

What may be interesting is to know the chips and other .config details of
the two cases reported here.  There may be an error in the Linux chip
implementation or something - I guess the random number generation may be
chip-specific but I don't know that much about the insides.

Just some thoughts.

John

John Logsdon                               "Try to make things as simple
Quantex Research Ltd, Manchester UK         as possible but not simpler"
j.logsdon at quantex-research.com              a.einstein at relativity.org
+44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com


On Mon, 15 Aug 2005, michal maly wrote:

> Hello,
> 
> on systems with pid randomization enabled (CONFIG_GRKERNSEC_RANDPID=y),
> following will happen (example):
> 
> $ time until /bin/false; do :; done
> 
> real    0m5.336s
> user    0m1.583s
> sys     0m3.308s
> 
> I used /bin/false to avoid shell builtin false.
> 
> This occurs, when pid number for a new process is chosen
> (gr_random_pid() in grsec_rand.c) and this pid is the same as pid of the
> former process. The new process will not be executed and will return a
> 'true' value (0). This will happen with probability of 1/pid_max (==
> 1/32768).
> 
> In logs you can see:
> 
> grsec: exec of /bin/false (/bin/false ) by /bin/bash[bash:25666]
> uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:5549]
> uid/euid:1000/1000 gid/egid:100/100
> grsec: exec of /bin/false (/bin/false ) by /bin/bash[bash:25666]
> uid/euid:1000/1000 gid/egid:100/100, parent /bin/bash[bash:5549]
> uid/euid:1000/1000 gid/egid:100/100
> 
> Both falses got 25666 and the latter ended with true.
> 
> 
> It can break some shell scripts and/or long running active systems.
> 
> I tested it on kernels 2.6.11.12-grsec and 2.6.7-grsec.
> 
> Michal Maly
> _______________________________________________
> grsecurity mailing list
> grsecurity at grsecurity.net
> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
>