Date: Sun, 31 Dec 1995 16:46:29 +1100 From: Bruce Evans <bde@zeta.org.au> To: dawes@rf900.physics.usyd.edu.au, smpatel@wam.umd.edu Cc: hackers@freebsd.org, jkh@time.cdrom.com Subject: Re: /dev/io Message-ID: <199512310546.QAA19107@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512310546.QAA19107>