Date: Tue, 17 Oct 1995 09:10:58 -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: <199510171410.JAA15571@miller.cs.uwm.edu>
next in thread | raw e-mail | index | archive | help
> Date: Tue, 17 Oct 1995 12:49:59 +1000 > From: Bruce Evans <bde@zeta.org.au> > To: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, > bde@zeta.org.au, cvs-sys@freefall.freebsd.org, james@miller.cs.uwm.edu > 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. > >> ... > >> /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 > > >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. > > Couldn't there be a server like the X server, or secure (ha!) setuid > capture programs? There could be, but you have to understand how much data video capture transfers. If there would be a suid server program, then that would require at least 2 memory copies -- one from the board to the server and one from the server to the client -- and probably one from the client to X. When you are talking about 640x480x2x30 bytes, this is a little unrealistic. I know that the ISA bus really can't run this fast, but depending on how fast one is willing to drive it, you are looking at atleast 4 meg/sec. The client must have direct access to the data without memory copies otherwise you will loose frames. That would mean the every video capture program would have to be suid - ugh! > > >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. > > The current way is actually to allow use of some privileged instructions, > including i/o instructions and disabling interrupts. Interrupts would > have to be disabled to stop the standard drivers from getting control > when when you subvert them :-). What I really need is the ability to do inb/outb for setting up the card from user land and reading 4 bytes from shared i/o memory. I wouldn't have to do the inb/outb if I could put the code into the driver, but then alas, non-disclosure. > > >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? > > Not yet. Here lies the problem... > > Bruce > -Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510171410.JAA15571>