>>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.

depends on your definition.  It's quite easy to accidentally retain
I/O access, if you're using a model like that provided by /dev/io.

That's what i meant.


>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.

yup.


> 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.

yup.  and LKMs, and a few other things that i'm forgettting right now,
only some of which are actually properly protes


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

I'm not familiar with the 'design misfeature' you speak of, but it is
pretty much unreasonable to expect a VGA X server on the pc to use
syscalls to do I/O port access...


> 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.

A better idea:

_DO_ restrict them, if security level == 1, as is appropriate, and
_require_ that people use 'options INSECURE' if they want to allow
them.  Ship the default kernels with 'options INSECURE' set.


Why bend (really, break) the security model to accomodate i386
brokenness?



cgd