Pavel Cahyna wrote:
> (http://www.netbsd.org/Ports/i386/faq.html#x_needs_insecure_kernel).
> 
> As the aperture driver won't be useful without allowing i386_iopl in
> securelevel 1, I would consider this as a known feature, too. (Or known

Holy smokes, did I read this thread right? We define a security level
that prevents arbitrary user access to device space ... and then we say
there's an X feature that won't work under those conditions, so you
can't use it at that securelevel ... unless you get this handy driver,
which itself works /only because of a disabled securelevel test in
the kernel/ ?

Isn't there a connection between acknowledging that this is the
deliberate creation of a false sense of security, and doing
something about it so it isn't?

One possibility would be as simple as adding a sysctl knob
allow_user_iopl, writable only in level 0. Let the test be
  if ( securelevel >= 1 && !allow_user_iopl ).
Let the sysctl knob be false by default. Document that the
aperture driver needs it to be true. Explain the implications
and let the admin make a deliberate choice to accept them.
Then at least it's not deceptive, and the admin can still
sensibly choose to use securelevel 1 for the obstacles it puts
in other paths of attack, even knowing this opens one path
around them.

Another possibility might be to look into whether there'd
be some way to piggyback on the veriexec machinery to be
sure that it's the unmodified X server making the iopl call,
and make the exception only in that case, though how to ensure
the X server integrity given its dynamic module loading would
be another question.

It seems to me the sysctl knob would be easy and could be
called urgent.

-Chap