[plug] Help needed - hackers/crackers and monolithic kernels

Shayne O'Neill shayne at guild.murdoch.edu.au
Fri Aug 5 13:02:39 WST 2005


Yep, and infact thats where a monolithic design perhaps does fall down,
because by keeping everything in Ring zero, you really only need to be
able to get some bad mojo code happining *anyware* in the kernel, and
separation be damned, the kernel is now owned. Oddly, thats where OS/X may
just have the advantage, in that somewhat oposite to the 2600 guys claim,
OS/X probably has more claim to be a micro kernel OS of sorts than linux
can due to its mach kernel.

--
Freedom's just another word for something new to regulate

On Fri, 5 Aug 2005, Cameron Patrick wrote:

> Shayne O'Neill wrote:
>
> > Truth be told, most of the kernel 'sploits are more to do with buffer
> > smashes, locking shenanigans and other out-of-bound value type stuff.
> > Something no design except good design can prevent.
>
> Sure, but if you had the kernel code following the "principle of least
> privilege" in the same way that most userland code {does, should do,
> can be made to do} then a buffer smash in, say, the USB driver could
> only affect USB devices, not give complete access to the whole
> system.  Whether any popular micro-kernel design actually _does_ this
> I have no idea.
>
> Given that most recent Linux sploits that I know about have taken
> advantage of things like system calls which didn't check their
> arguments or bugs in interpreting the header fields of executables --
> stuff which by its nature needs access to poke stuff into random bits
> of system memory -- I'm not really sure how effective that kind of
> kernel-level privilege separation would actually be.
>
> Cameron.
>
>
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au
>



More information about the plug mailing list