>> I guess it sure makes sense. It has occured to me that opening /dev/io was
>> a little too all-or-nothing.
>
>Slightly worse than that, I think: it's a security hole in the making.
>
>consider, if I/O access enabled by open of /dev/io, and I/O access
>revoke by close:
>
>UNIX driver semantics say that the driver sees every open -- and
>therefore frob bits in the proc doing the opening, if it wants -- but
>only sees the _last_ close.
>
>"oops."

All of this stuff is a security hole, and not just in the making.

Allowing root, when at securelevel > 0, to frob arbitrary addresses in IO
space, punches a huge gaping hole in the guarantees provided by the multilevel
security.

This implies that, if we gave a damn about the security model, both the
i386_iopl() syscall and the KBD_ENABIO ioctl (which is deprecated but
equivalent) would be right out.

Unfortunately due to a design misfeature of XFree86, enforcing the proper
security-level restrictions on this stuff is politically unacceptable.

A hypothetical:  Does anyone see any reason why these holes ought not be
plugged at securelevel=2?  If you're running there, you've probably made a
conscious choice to accept inconvenience for the sake of security.

Thor