by mail.netbsd.org with SMTP; 25 Aug 2000 00:16:55 -0000
	by mail1.panix.com (Postfix) with ESMTP
	id 3AA73310EE; Thu, 24 Aug 2000 20:16:54 -0400 (EDT)
Date: Thu, 24 Aug 2000 20:16:54 -0400
From: Thor Lancelot Simon <tls@rek.tjls.com>
To: tech-kern@netbsd.org
Cc: tech-security@netbsd.org
Subject: Re: lseek(2) & read(2) on raw cd(4) device
Message-ID: <20000824201654.A26254@rek.tjls.com>
Reply-To: tls@rek.tjls.com
References: <20000824221018.18C04884@sean.ebone.net> <20000825001913.B14176@beverly.kleinbus.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20000825001913.B14176@beverly.kleinbus.org>; from is@beverly.kleinbus.org on Fri, Aug 25, 2000 at 12:19:13AM +0200

On Fri, Aug 25, 2000 at 12:19:13AM +0200, Ignatios Souvatzis wrote:
> On Fri, Aug 25, 2000 at 12:10:18AM +0200, Sean Doran wrote:
> > 
> > | #         if (CDPART(bp->b_dev) != RAW_PART &&
> > |
> > | um, /dev/r?d[0-9]*[a-h] are raw partitions.
> > | /dev/?d[0-9]*[a-h] are block partitions.
> > 
> > Uhm, "raw partitions" is a bad term; 'un-blocked interfaces' perhaps is clearer?
> > 
> > RAW_PART (see above) is defined in places like this:
> > 
> > ./arch/i386/include/disklabel.h:#define RAW_PART        3
> >                /* raw partition: XX?d (XXX) */
> > 
> > ./arch/alpha/include/disklabel.h:#define        RAW_PART        2
> > 	       /* raw partition: xx?c */
> > 
> > So, having learned alot about the "BSD way" of lseek versus vnodes,
> > can anyone explain to me why we don't do bounds-checking on RAW_PART in
> > cdstrategy/sdstrategy/etc.?
> 
> We can't because (at least for disks) we use it to read and write the disk
> label, when there isn't any.

Note that this is a significant security hole, violating the "securelevel"
model: disksubr neither bounds-checks nor checks for overlap on the raw
partition; worse, it doesn't check for overlap between *any* partitions,
with the result that even at securelevel 1, you can write a new disklabel
with a partition that overlaps the one on which you wish to modify immutable
binaries, and away you go.

We really need to move *all* disklabel-writing code into the kernel.