Except that (please correct me if I'm wrong) I think that L4Linux runs all drivers in the same process as the Linux kernel. So the kernel is not protected from interference from the drivers. Of course, this was done to make it easier to put Linux on top of L4, which is fair enough, so.
As the "kernel" is running in user mode rather than kernel mode, there can be memory protection. But doing this (especially with Linux drivers' like of playing with kernel data structures) would, I think, be nearly as hard as turning Linux into a multi-server microkernel anyway.
So the Linux kernel could still be compromised in L4Linux. Then anything spawned by the Linux kernel could be compromised. The driver could map new pages into any Linux process to run arbitrary code.
In this case processes which were not spawned by the Linux kernel and which did not trust any Linux processes would be unaffected. They could possibly check for exploits. It still wouldn't be easy, though, with filesystem drivers running in the Linux kernel (h4x0red;-)), and this process couldn't be started by a Linux process after the bad driver had been loaded.
The driver could also overwrite this process on disk. So upon reboot, a bad kernelkit-checker is loaded. The checker will need to get it right every time before the system is rebooted, with an untrusted file system. I think that hard isn't a strong enough word:-)
If the driver was run as a separate process, then it couldn't destroy everything like this without using buffer overruns and suchlike. It can only destroy things in its own address space. With the whole Linux kernel and drivers in one process, that advantage of microkernels almost disappears.
Running Windows NT as an administrator gives you far less power than running Unix as root.
Administrators can be stopped, just like any other user, from having access to certain files, or certain registry keys.
By default, they can take ownership of other files and keys in order to set the permissions. After all, the sysadmin will need to do that sometimes. But that can be disabled using Group Policy. Administrator is not all-powerful.
In the same way, Administrator can be denied the ability to load device drivers. This will stop these attacks.
As to your third flaw, about hijacking of system calls: a ring 0 driver can do anything at all. There is no way - *no way* - to prevent a malicious driver from intercepting system calls when it runs in ring 0. In this regard a microkernel would be much better than either Linux or Windows.
After years of waiting, nothing came. And you realise you're looking in the wrong place. I'm a reasonable man, get off my case, get off my case, get off my case.
Search for 'Search' on Google: search.com AltaVista Yahoo Excite All TheWeb Lycos...
Search for 'Search' on new MSN: Vault: the most trusted name in career information Destiny Group CareerBuilder Realtor.com Lycos People Search
So, the fifth link on MSN is nearly - but not quite - relevant.
Incidentally, Google doesn't list itself until 20th when you search for "search" on it. Which is interesting... maybe it's because of its minimalistic website which doesn't mention searching very much.
In Soviet Russia, the subatomic particles are made out of you!
/me goes back to doing not much at all
Oh, wait. That doesn't make any sense at all. Bugger. Oh well, never mind.
Sort of. I like L4 a lot :-).
;-)), and this process couldn't be started by a Linux process after the bad driver had been loaded.
:-)
Except that (please correct me if I'm wrong) I think that L4Linux runs all drivers in the same process as the Linux kernel. So the kernel is not protected from interference from the drivers. Of course, this was done to make it easier to put Linux on top of L4, which is fair enough, so.
As the "kernel" is running in user mode rather than kernel mode, there can be memory protection. But doing this (especially with Linux drivers' like of playing with kernel data structures) would, I think, be nearly as hard as turning Linux into a multi-server microkernel anyway.
So the Linux kernel could still be compromised in L4Linux. Then anything spawned by the Linux kernel could be compromised. The driver could map new pages into any Linux process to run arbitrary code.
In this case processes which were not spawned by the Linux kernel and which did not trust any Linux processes would be unaffected. They could possibly check for exploits. It still wouldn't be easy, though, with filesystem drivers running in the Linux kernel (h4x0red
The driver could also overwrite this process on disk. So upon reboot, a bad kernelkit-checker is loaded. The checker will need to get it right every time before the system is rebooted, with an untrusted file system. I think that hard isn't a strong enough word
If the driver was run as a separate process, then it couldn't destroy everything like this without using buffer overruns and suchlike. It can only destroy things in its own address space. With the whole Linux kernel and drivers in one process, that advantage of microkernels almost disappears.
Running Windows NT as an administrator gives you far less power than running Unix as root.
Administrators can be stopped, just like any other user, from having access to certain files, or certain registry keys.
By default, they can take ownership of other files and keys in order to set the permissions. After all, the sysadmin will need to do that sometimes. But that can be disabled using Group Policy. Administrator is not all-powerful.
In the same way, Administrator can be denied the ability to load device drivers. This will stop these attacks.
As to your third flaw, about hijacking of system calls: a ring 0 driver can do anything at all. There is no way - *no way* - to prevent a malicious driver from intercepting system calls when it runs in ring 0. In this regard a microkernel would be much better than either Linux or Windows.
After years of waiting, nothing came.
;-)
And you realise you're looking in the wrong place.
I'm a reasonable man, get off my case, get off my case, get off my case.
Err, sorry. Got carried away there
That's like what... 10^1000 USD/year? Not bad. ;-)
Search for 'Search' on Google:l TheWeb ...
search.com
AltaVista
Yahoo
Excite
Al
Lycos
Search for 'Search' on new MSN:
Vault: the most trusted name in career information
Destiny Group
CareerBuilder
Realtor.com
Lycos People Search
So, the fifth link on MSN is nearly - but not quite - relevant.
Incidentally, Google doesn't list itself until 20th when you search for "search" on it. Which is interesting... maybe it's because of its minimalistic website which doesn't mention searching very much.