Date: Mon, 6 Dec 1999 11:00:59 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Brad Knowles <blk@skynet.be> Cc: Sheldon Hearn <sheldonh@uunet.co.za>, obrien@freebsd.org, arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Message-ID: <Pine.BSF.3.96.991206105429.10466B-100000@fledge.watson.org> In-Reply-To: <v0422080ab4714b845138@[195.238.21.204]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Dec 1999, Brad Knowles wrote: > At 12:53 PM +0200 1999/12/6, Sheldon Hearn wrote: > > > Nah, just leave the historical linear assignment as the default mode > > of operation for the sake of POLA and document the knob for random > > assignment in rc.conf.5 and wherever else might be appropriate. > > I don't suppose that this is a democracy, and that we can each > vote for the default we want to have, can we? > > > I can't speak for the "convenience" of having linear PID > assignment (I just can't imagine a way that anyone could take > advantage of this in a "good" way). > > However, I can say that there are a boatload of dain-bramaged > scripts out there that I think would have their security measurably > increased (even if by a small amount), if this option were turned on. > Hell, I think just about every script I've ever written would fall in > this category. ;-) An interesting, although perhaps not useful, observation is that an attacker can easily coerce linear PID allocation to non-linear allocation, even without an account on the machine. Most daemons are quite happy to fork children with little provocation (i.e., a connection) and this chews through the PID space. Similarly, given an account, they can run #include <unistd.h> while (1) if (fork()) exit(0); So it's clear that nothing should *rely* on linear allocation if it's going to resist disruption as the result of an attack. On the other hand, it has usefully been observed that poorly written scripts (over which we have no control, so can't fix) have been vulnerable as a result of predictable PID allocation--and while we can force non-linear PID allocation, there is no way for us to force linear allocation :-). I vote yes on this change (not that it's a democracy). On any busy system, especially an SMP machine, linear allocation of PIDs is an unsafe assumption, even during the boot process where, for example, named will spawn off an indefinite number of named-xfers based on third party changes to zone files, or where sendmail (and even route add default) are willing to block based on network conditions (name lookup availability), screwing around with ordering of events. For most debugging purposes, /var/run/whatever.pid, the PPID entry, and accounting (if desired) are quite adequate replacements. And there's always killall :-). Robert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991206105429.10466B-100000>