Security issues

Matthias Hopf mhopf at
Fri Apr 21 04:41:47 PDT 2006

On Apr 21, 06 11:25:28 +0200, Duflot Loic wrote:
> > why not? insmod kernelmodle.ko - don't. io just inserted code into the kernel.
> > root is allowed to do it. there's /dev/mem for more fun. the list goes on. :)
> If you have time, take some time to look at the OpenBSD man page for
> "securelevel". You will see that once the securelevel is raised, it is
> no longer possible to load (or unload for that matter) kernel modules.
> It is also no longer possible to write to /dev/mem... That is the whole
> point of the securelevel mechanism.

In that case in the current state X shouldn't be allowed to be run any
more. In fact, if the kernel interface would be as secure as it is
pointed out, X *couldn't* run any longer, because it couldn't obtain
those critical resources any longer.

As long as X is still able to run in securelevel, the interface is not
safe. Because an attacker could write a program using similar interfaces
as the the Xserver, start it, and gain kernel access.

> But I do not agree that we should not move forward. I mean, why should a
> "kernel" component (as you say) run in userspace? Why should this be
> Accepted?

Because it eases development, it would never be accepted in the kernel,
it is too heavyweight, process abstraction and memory management is
something really nice to have, ...

The list goes on.

Actually, current movement is in the oposite direction: towards user
level drivers (WLAN, modems, graphics drivers, AFAIR even sound cards).

> A few years ago it was accepted that women should not vote...
> Fortunately enough, somebody was bold enough to actually decide it
> should be otherwise... ;-)

Please don't compare.


Matthias Hopf <mhopf at>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at
Phone +49-911-74053-715            __)  |_|  __)  |__  labs

More information about the xorg mailing list