From owner-freebsd-hackers  Sun Dec 31 02:09:21 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id CAA17858
          for hackers-outgoing; Sun, 31 Dec 1995 02:09:21 -0800 (PST)
Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA17851
          for <hackers@freebsd.org>; Sun, 31 Dec 1995 02:09:14 -0800 (PST)
Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.6.11/8.6.9) id VAA17343; Sun, 31 Dec 1995 21:09:07 +1100
From: David Dawes <dawes@rf900.physics.usyd.edu.au>
Message-Id: <199512311009.VAA17343@rf900.physics.usyd.edu.au>
Subject: Re: /dev/io
To: bde@zeta.org.au (Bruce Evans)
Date: Sun, 31 Dec 1995 21:09:07 +1100 (EST)
Cc: hackers@freebsd.org
In-Reply-To: <199512310819.TAA23798@godzilla.zeta.org.au> from "Bruce Evans" at Dec 31, 95 07:19:11 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
Precedence: bulk

>>If this can be done OK, then I don't think there would be problems with
>>the same ports being used for both security holes and normal operations
>>providing the /dev/fb device is single-open (to prevent spying on the
>>fb contents).  Making it single-open prevents the running of multiple
>>servers, or use of the new DGA extension, but I think that's inevitable
>>at a high security level.
>
>The mapped ports can be determined by accessing them and seeing if a
>signal is generated (unless the kernel traps these accesses specially).
>Anyway, port like 3D4/3D5 are likely ;-) to be mapped and they only
>need one insecure index register in them to cause problems.
>
>I think these problems are best handled by not allowing the X server to
>be restarted (is that what you meant by "prevents running of multiple
>servers").  Start the X server and let it grab I/O permissions and

I meant running more than one server simultaneously.  The ability to
do this implies the ability for someone to access the video hardware
while a server is running, and that can be considered insecure.  Then
again I suppose being able to start a server at all while in secure mode
is insecure because it implies the ability to snoop on the text screen.

>memory maps the same as now before entering secure mode, and don't allow
>these operations at all in secure mode.  This reduces that problem to
>the usual one of protecting the server's text and data after it has
>started.

This is a rather sever limitation though.  There are lots of reasons
why you might need to restart a server (the most obvious is if it crashes).
However, if you really need a secure environment, this may be acceptable.
Some might argue that you shouldn't run an X server at all on a machine
that really needs to be secure.

David