>>>>>> "Dave" == Dave <[EMAIL PROTECTED]> writes: > > Dave> Seems like the critical link to be fixed is the vulnerability of > Dave> daemons that run with root privilege and receive input from users. > >No. The kernel itself has bug. The "user" (attacker) is running *perfectly >legitimate* system calls (brk(), the call that will be made when you >malloc()) from a rather strange but allowed executable file (that have the >code segment moved to the end of address space). And then, due to the >kernel bug, the user can write into arbitrary location in the kernel, do >whatever he wants. So here the problem is the kernel---the ultimate source >of permission that you have on the computer. If the kernel is buggy, there >is really little that you can do to be protected from being harmed---except >of course to have a network of mutually distrusting servers with completely >different passwords, keys, etc.
Good point. Instead of "daemons", I should have said "daemons (or any kernel routines)"
It still seems like it should not be difficult isolate the user input, and force it to flow through a "narrow channel" where we can test it carefully for excess length, or any other irregularities that might cause a breach of security. I'm using colorful language here, because I don't understand the details of how bad input gets read into priveledged code. I just have a general intuition that it could be "channeled", the way access to supervisor mode is done in a modern microprocessor.
Instead of a mode where the user can write anything he wants into memory, imagine an OS that works something like this:
(Again, please excuse my fanciful imagination.)
User: CallService DestroyFileSystem <victim's partition> OS: Sorry, no such service. User: CallService 227 OS: Sorry, no such service. User: CallService 226 226> OpenForWrite <victim's filename> Sorry, you don't have permission to write to someone else's files. 226> PokeMemory <some address> Sorry, service 226 has no such command. 226> SaveThisData <very long string> Sorry, your data exceeds the size of my buffer. 226>
I've shown this as an interaction, but it could be just a single call with all the parameters. The point I'm trying to make is that the OS has only a very limited set services offered, and each service has very limited and carefully checked input it will accept. There is no such thing as a "buffer overflow" because all raw input goes through some *common routine* that at leasts checks for maximum length.
So how many daemons and kernel routines need both root access and input from a user process?
-- Dave
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
