Security issues

[Matthieu Herrb]

Matthias Hopf wrote:
> 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).

There is a difference between moving some processing code out of the 
kernel (or keeping it out of the kernel) and letting userland access all 
of the system's hardware resources.

Separating root and kernel privilege is something that most 
security-aware systems want. Many system are even moving to finer grain 
privilege management in userland. In those models you cannot accept that 
the privilege needed to run X (or any other device whose driver moved to 
userland) potentially opens full kernel access.

I think there are some projects in X.Org to separate the mode settings 
from the X server. This paper clearly shows that at least some parts of 
this has to move into the kernel.

I know less about DRI or EGL drivers, but the principle is the same: 
access to the hardware need to be controlled by the kernel, so that dma 
sources and destination, i/o ports and so on are checked for validity by 
the kernel before beeing used by userland.

And of course, this would be easier with sounder hardware design, but 
this is out of the scope of X.Org.
-- 
Matthieu