Subject: Re: lseek(2) & read(2) on raw cd(4) device
To: None <tech-kern@netbsd.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 08/24/2000 20:16:54
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.