Dave wrote: > Recent discussions in this group have raised as many questions for me as > they have answered, and raised doubts in my mind that the security of the > Linux kernel will ever be as good as I would like it to be. Is there a > fundamentally simple and 100% effective way to stop kernel exploits, or > will we be forever locked in a race between white hats and black hats? I'm afraid that there is a stock answer one receives when one asks questions like these on internet discussion lists. I won't bother to give it as I'm sure someone will before this mail propigates out. > I am still hoping kernel security will eventually be as good as the security > of a typical microprocessor instruction set. Throw a trillion bad inputs > at an x86 microprocessor, and you will never take over the "supervisor" > mode. Touching faith in hardware. Pity it doesn't live up to it. Hardware is put together by humans, using tools increasingly similar to the tools we use to write software, and humans make mistakes. There has been at least one mistake in Intel hardware which had effects as bad as you describe; I alluded to it in my earlier mail. I think you'll find that a trillian bad inputs thrown at the linux kernel or any random setuid program are also unlikly to get you root (maybe a crash if you're lucky), but careful study and a targeted attack has much better luck. > [1] Are the parts of the kernel that need to be fast the same parts that > read input from a user process, It depends on your workload, but under most, yes, syscalls are very frequent, and their speed is essential. Something as simple as getting the current time, which is perhaps the most common syscall on desktop machines, involves passing a pointer to the kernel for it to write the time to. (However, that syscall has been at least partly moved to user space; I forget the details). > or can we say that 95% of user inputs can > be passed through robust, standardized validation routines with no > performance degradation noticeable to the user? e.g. When the user > process says "Here's a pointer to my data.", should a kernel routine just > start stuffing a buffer, or call a common routine that at leasts checks > the length of the data to be stuffed. If "blind buffer stuffing" were > limited to just those routines where this transaction was time-critical, > then those few routines could get a lot of scrutiny for buffer overflows. I think that you'll find that all accesses of data in user space by syscalls goes through a set of functions that do size checking and other checks. I think you'll find that the kernel is not in the business of trading off correctness for speed and instead they generally manage both. Except, of course, when mistakes are made. Some of the relevant code is several of the files in kernel/ or fs/read_write.c/open.c, depending on which syscalls you're intrested in, plus linux/arch/i386/lib/usercopy.c, and linux/include/asm-i386/uaccess.h If you're looking for more assurance than that, I think you'll quickly fall into a need for formal correctness proofs, which are probably very difficult for something with the scope of the linux kernel. > [3] I'm not sure what is meant by "tainted inputs" here. My guess is we > are talking about inputs that would pass simple validation checks (string > lengths, number ranges, membership in an allowed set) but still cause a > subtle problem later. It seems like that kind of problem would be very > unlikely, and almost impossible to exploit for anything other than causing > a crash. I'm comparing this situation to the comparable vulnerability with > microprocessor instruction sets, and we don't see that happening. There is vast potential for that kind of thing, particularly in the syscalls that manipulate files. Lots of potential for races, many ways to add malicious data to try to mess the kernel up (think of chains of recursive symlinks, for example). There have been many fixes in this area in the past. -- see shy jo
Attachment:
signature.asc
Description: Digital signature