by mail.netbsd.org with SMTP; 25 Aug 2000 03:16:23 -0000
Date: Thu, 24 Aug 2000 20:13:59 -0700 (PDT)
From: Bill Studenmund <wrstuden@zembu.com>
To: Thor Lancelot Simon <tls@rek.tjls.com>
cc: tech-kern@netbsd.org, tech-security@netbsd.org
Subject: Re: lseek(2) & read(2) on raw cd(4) device
In-Reply-To: <20000824201654.A26254@rek.tjls.com>
Message-ID: <Pine.NEB.4.21.0008241953450.749-100000@candlekeep>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 24 Aug 2000, Thor Lancelot Simon wrote:

> > 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.

That won't work for a number of partitioning schemes. For Apple Partition
Map partitioned disks, the "disklabel" is spread over the first say 20
blocks of the disk. Having the kernel being able to modify these
partitions strikes me as a real mess. That's a job best left to userland
partitioning programs. Especially when you take things to the extreme of
letting every port be able to modify every other disklabel type - that's
best left to user apps.

I think a solution which will do what you want & I want is to impliment
something like Ultrix's disklabel protection. In the higher secure modes,
you won't be able to write to the blocks which hold the disklabel. That
way we prevent the overwriting of immutable binaries without putting
disklabel writing into the kernel.

One other advantage of this is that the disklabel code can report a range
of protected blocks. For Apple partition maps, that would cover the whole
partition map (which is itself a partition in the partition map). Also (a
cool extrapilation) MBR partitioning could protect both the MBR and the
struct disklabel in the head of the NetBSD partition! :-)

Thoughts?

Take care,

Bill