Re: /proc/sys/kernel/pid_max issues

[Herbert Poetzl <herbert@13thfloor.at>]

On Mon, Sep 13, 2004 at 07:27:52AM -0700, William Lee Irwin III wrote:
> On Mon, 2004-09-13 at 03:42, William Lee Irwin III wrote:
> >> The resource tracking and locking implications of this are disturbing.
> >> Would fully pseudorandom allocation be acceptable?
> 
> On Mon, Sep 13, 2004 at 10:11:29AM -0400, Albert Cahalan wrote:
> > There's no point.
> > LRU reduces accidents that don't involve an attacker.
> > Strong crypto random can make some attacks a bit harder.
> > OpenBSD does this. It doesn't work well enough to bother
> > with if the implementation is problematic; there's not
> > much you can do while avoiding 64-bit or 128-bit PIDs.
> > Pseudorandom is 100% useless.
> > Per-user PID recycling would make it much harder for
> > an attacker to grab a specific PID. Perhaps the attacker
> > knows that a sched_setscheduler call is coming, and he
> > has a way to make the right process restart or crash.
> > Normally, this lets him get SCHED_FIFO or somesuch.
> > With per-user PID recycling, it would be difficult for
> > him to grab the desired PID.
> 
> I'd suggest pushing for 64-bit+ pid's, then. IIRC most of the work
> there is in userspace (the in-kernel part is trivial).

except for the various 'assumptions' done in procfs
to create the inode numbers ... but that is a different
story ...

best,
Herbert

> -- wli
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/