[RFC] pid randomness

[RFC] pid randomness

[Pedro Venda (SYSADM)]

hi everyone,

I don't know if this has been discussed before... but I'd like to ask 
why isn't the pids randomized by default?

I mean, of course it's not required for normal functioning but it'd be 
nice to have a Kconfig option to make it happen.

The (newbie) way I see it, it'd not be hard to do... generate pid, check 
if it's unique, give pid to process. It could bring some minor security 
enhancements while taking a slight performance hit (seek & compare 
algorithm for used pids).

What are the pros and cons of this? What are your oppinions on this subjet?

regards,
pedro venda.
-- 
Pedro João Lopes Venda
email: pjvenda@rnl.ist.utl.pt
http://maxwell.rnl.ist.utl.pt

Equipa de Administração de Sistemas
Rede das Novas Licenciaturas (RNL)
Instituto Superior Técnico
http://www.rnl.ist.utl.pt
http://mega.ist.utl.pt

Re: [RFC] pid randomness

[Jan Engelhardt]

> I don't know if this has been discussed before... but I'd like to ask why isn't
> the pids randomized by default?
> What are the pros and cons of this? What are your oppinions on this subjet?

Why would _you_ need it?



Jan Engelhardt
-- 
ENOSPC

Re: [RFC] pid randomness

[Pedro Venda (SYSADM)]

Jan Engelhardt wrote:
>>I don't know if this has been discussed before... but I'd like to ask why isn't
>>the pids randomized by default?
>>What are the pros and cons of this? What are your oppinions on this subjet?
> 
> 
> Why would _you_ need it?

It's a simple security measure that I think is easy to implement.

I'd agree that it's not there because of the golden rule: "keep it 
simple", but I'd also like to know if that's really the reason it's not 
there.

and yes, I know there are some patch sets that already implement this.

regards,
pedro venda.
-- 
Pedro João Lopes Venda
email: pjvenda@rnl.ist.utl.pt
http://maxwell.rnl.ist.utl.pt

Equipa de Administração de Sistemas
Rede das Novas Licenciaturas (RNL)
Instituto Superior Técnico
http://www.rnl.ist.utl.pt
http://mega.ist.utl.pt

Re: [RFC] pid randomness

[David Martin]

Hi,

You have an implementation of this and other stuff on grsecurity 
(www.grsecurity.net) patch for both 2.4 and 2.6 kernel. It is intented for 
servers, critical machines, or just paranoic users :)

cheers,
david.

On Monday 27 December 2004 20:39, you wrote:
> hi everyone,
>
> I don't know if this has been discussed before... but I'd like to ask
> why isn't the pids randomized by default?
>
> I mean, of course it's not required for normal functioning but it'd be
> nice to have a Kconfig option to make it happen.
>
> The (newbie) way I see it, it'd not be hard to do... generate pid, check
> if it's unique, give pid to process. It could bring some minor security
> enhancements while taking a slight performance hit (seek & compare
> algorithm for used pids).
>
> What are the pros and cons of this? What are your oppinions on this subjet?
>
> regards,
> pedro venda.

-- 
This device complies with part 15 of the FCC rules. Operation is
subject to the following two conditions:
(1) This device may not cause harmful interference,
(2) This device must accept any interference received, including 
    interference that may cause undesired operation.

Re: [RFC] pid randomness

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

On Mon, 27 Dec 2004 19:39:01 GMT, "Pedro Venda (SYSADM)" said:

> I don't know if this has been discussed before... but I'd like to ask 
> why isn't the pids randomized by default?

It's a pretty easy thing to do, actually.  There's a patch for that
in Grsecurity, and I did one up myself a while ago...

One big problem that remains beyond my technical skill to fix - for the
32 bit machines, there's some funkiness in the /proc filesystem code
where it invents inode numbers based in the process ID that restrict the
effective value of max_pid to 64K.  Unfortunately, if you're in the camp that
believes that randomizing the PID is useful at *all*, you probably want a
bigger space for the random number.  So you can either fix that issue (and
whatever *OTHER* issues lurk after that one) or only deploy on 64 bit boxen...

A secondary issue that I've never been able to test is whether over time,
a "randomized" PID ends up sparsely dirtying the list of pidmap pages (so
you have enough pages to hold 4M PID bits, but only 1 or 2 bits per page
are actually set), or do the occasional long-lived processes end up essentially
leaving at least one process on each page anyhow?  Any operational experience
on that one from the big-system guys?

At worst, 4M pids will take 128 4K pages (or equivalent for other page sizes) -
is that considered "unacceptable" on 64-bit boxes that want to do this?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]