From owner-freebsd-security  Fri Feb 27 08:10:21 1998
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA10072
          for freebsd-security-outgoing; Fri, 27 Feb 1998 08:10:21 -0800 (PST)
          (envelope-from owner-freebsd-security@FreeBSD.ORG)
Received: from ns1.yes.no (ns1.yes.no [195.119.24.10])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10058
          for <freebsd-security@FreeBSD.ORG>; Fri, 27 Feb 1998 08:10:17 -0800 (PST)
          (envelope-from eivind@bitbox.follo.net)
Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36])
	by ns1.yes.no (8.8.7/8.8.7) with ESMTP id QAA01903;
	Fri, 27 Feb 1998 16:10:15 GMT
Received: (from eivind@localhost)
	by bitbox.follo.net (8.8.6/8.8.6) id RAA00504;
	Fri, 27 Feb 1998 17:09:54 +0100 (MET)
Message-ID: <19980227170953.30435@follo.net>
Date: Fri, 27 Feb 1998 17:09:54 +0100
From: Eivind Eklund <eivind@yes.no>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>,
        Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca>
Cc: freebsd-security@FreeBSD.ORG
Subject: Re: OpenBSD Security Advisory: mmap() Problem
References: <19980226174359.3210.qmail@joshua.enteract.com> <199802270423.UAA01955@cwsys.cwsent.com> <199802271501.KAA04815@khavrinen.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <199802271501.KAA04815@khavrinen.lcs.mit.edu>; from Garrett Wollman on Fri, Feb 27, 1998 at 10:01:50AM -0500
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk

On Fri, Feb 27, 1998 at 10:01:50AM -0500, Garrett Wollman wrote:
> <<On Thu, 26 Feb 1998 20:23:06 -0800, Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> said:
> 
> > crashes trying to access the VT.  To get the XIG Accelerated X server 
> > to work I've modified the patch to allow superuser to access to 
> > character devices.
> 
> The would be pointless.

It'd kill the securelevel facility, but it would still remove the kmem
=> root exploits.  But it isn't good enough, I agree.  Perhaps denying
the transition only when !(root || securelevel > -1) would be a
potential solution?  It'd allow AccelX to keep working (AFAIK, it
won't work with securelevel > 0 anyway) and it would stop all real
violations I can think of

1. root can't lower the securelevel
2. kmem can't get privileges it shouldn't have
3. root will get some privileges it could get some privileges it would
   have anyway if it had opened in another mode. This will make us
   vulnerable to the unlikely exploit of somebody getting hold of a
   root mmap() pointing at a character device, but _not_ being able to
   execute arbitary code.  Sounds unlikely to me.

Have I covered everything?  (Perhaps there are some special /dev/mem
interactions I don't know of...)

Eivind, who don't really like this solution, either, but if the
alternative is leaving the bug wide open...

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message