From owner-freebsd-arch Mon Dec 6 8: 1:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A961214E30 for ; Mon, 6 Dec 1999 08:01:21 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA07379 for ; Mon, 6 Dec 1999 17:01:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA08984 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 17:01:19 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2B2E814E30; Mon, 6 Dec 1999 08:01:07 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA10811; Mon, 6 Dec 1999 11:00:59 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Dec 1999 11:00:59 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Brad Knowles Cc: Sheldon Hearn , 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 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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