From owner-freebsd-hackers Sat Dec 30 21:51:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA09112 for hackers-outgoing; Sat, 30 Dec 1995 21:51:25 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA09106 for ; Sat, 30 Dec 1995 21:51:10 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA19107; Sun, 31 Dec 1995 16:46:29 +1100 Date: Sun, 31 Dec 1995 16:46:29 +1100 From: Bruce Evans Message-Id: <199512310546.QAA19107@godzilla.zeta.org.au> To: dawes@rf900.physics.usyd.edu.au, smpatel@wam.umd.edu Subject: Re: /dev/io Cc: hackers@freebsd.org, jkh@time.cdrom.com Sender: owner-hackers@freebsd.org Precedence: bulk >> For what it's worth, the XFree86 servers get I/O permission by using >> the KDENABIO ioctl in the console driver rather than by opening /dev/io. >I wasn't even aware that this existed, but looking at the Xserver source >it seems like BSDI, Linux, FreeBSD, and NetBSD all have it (but only >Free/NetBSD use it for Xserver IO permission). I wasn't aware that /dev/io existed for a long time :-). >This makes it even easier to phase out /dev/io, because the Xservers will >not break and the code for iopl() would be very similar to the code for >the KDENABIO ioctl. I prefer to have this security hole in only one device. I/O permission should not be allowed when securelevel >= 2. One way of implementing this is to remove all of the other holes and classify /dev/io as a kmem device and change its interface so that a write() is required to get I/O permission. (iskmem() really means that writing to the device is a security hole.) >The only non-trivial thing would be implementing IO >permission bitmaps, but I'm not even sure if it's worth it since it would >be a rarely used feature. I think they are only worth it if you want to use securelevel >= 2 and things like X. Bruce