From owner-cvs-sys  Mon Oct 16 07:45:52 1995
Return-Path: owner-cvs-sys
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id HAA10026
          for cvs-sys-outgoing; Mon, 16 Oct 1995 07:45:52 -0700
Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA10014
          ; Mon, 16 Oct 1995 07:45:38 -0700
Received: (from james@localhost) by miller.cs.uwm.edu (8.6.10/8.6.10) id JAA16277; Mon, 16 Oct 1995 09:45:37 -0500
Date: Mon, 16 Oct 1995 09:45:37 -0500
From: Jim Lowe <james@miller.cs.uwm.edu>
Message-Id: <199510161445.JAA16277@miller.cs.uwm.edu>
To: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org,
        bde@zeta.org.au, cvs-sys@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/i386/isa spigot.c
Sender: owner-cvs-sys@FreeBSD.org
Precedence: bulk

> Date: Sat, 14 Oct 1995 18:00:57 +1000
> From: Bruce Evans <bde@zeta.org.au>
> To: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org,
>         cvs-sys@freefall.freebsd.org
> Subject: Re: cvs commit: src/sys/i386/isa spigot.c
> 
> >  Modified:    sys/i386/isa  spigot.c
> >  Log:
> >  Don't allow i/o operations for non-root users.
> 
> This change should probably be in 2.1.  I'm not sure what the spigot
> driver and the encumbered libraries for it do, but they shouldn't
> be allowed to de-scure the rest of the system.
> 
> /dev/spigot is created with owner root.wheel and permissions 444.  This
> was previously a security hole. Now it is probably just bogus since
> probably only root will be able to use the device.  Perhaps the correct
> fix was to change /dev/spigot to owner root.kmem permissions 440.  Then
> it would be as (in)secure as /dev/io.  Granting i/o permission is more
> dangerous than granting read-only permission for /dev/kmem, so there
> should be a separate group and stronger enforcement of kern.securelevel
> for it.  /dev/mem should probably be in the same group, since reading
> device registers may cause output.
> 
> Bruce
> 
At the time I wrote the spigot stuff, this seemed the only way to make
things work.  On many systems, making people run as root to capture video
is far more insecure than granting them access to the IO page, but this
is a matter of judgement.

In my case, running a video capture program as root would basically
be the same thing as giving every user on that system root priv since
they use the system to capture video.  This doesn't sound like a
reasonable solution either.

The correct solution would be to map the 4 bytes of i/o space
(read-only) into user space.  With the current vm functions available,
I didn't see any way of doing this.  It seemed that one had to map all
of i/o space or none at all.

Is there a way of mapping one word of I/O space read-only into user space
without allowing them access to the whole I/O page?

	-Jim