Date: Mon, 16 Oct 1995 09:45:37 -0500 From: Jim Lowe <james@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 Message-ID: <199510161445.JAA16277@miller.cs.uwm.edu>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510161445.JAA16277>