Messages in this thread | | | Date | Thu, 30 Dec 1999 21:57:01 -0800 (PST) | From | Robert Dinse <> | Subject | Re: linux-kernel-digest V1 #4990 |
| |
On Thu, 30 Dec 1999 Horst von Brand <vonbrand@pincoya.inf.utfsm.cl> wrote: > > Linus stated it _won't_ go into the kernel, because it just papers over > bugs in userland code, and buys very little (if any) extra security, and > moreover breaks legitimate programs. He outlined ways to use stack > overflows even in this case, and to think crackers won't be able to use > them just because they are harder to get right (note that those attacks > will also work on unpatched systems) is delusion. Dangerous one.
You keep saying Linus said this but I've been subscribed to this list for several months now and must have missed it. Presumably Linus is capable of speaking for himself. I know he is, I've seem him speak, usually rather forcefully, on other issues.
I don't understand your logic at all. First I am convinced you are the only one that might potentially suffer from this delusion you keep bringing up. I don't think any of us who want this capability are under any such delusion that it's going to bring absolute security, I think we've all elaborated on that fact rather extensively.
Further, if we follow your logic to the extreme, hell, we might as well get rid of UID/GID and file permissions altogether. No program will ever do the wrong thing. We can speed up the operating system by eliminating ALL parameter sanity checking at all system calls, after all that should be in userland, and if the userland code does the right thing it won't be a problem.
Get realistic; part of the responsibilities of the kernel is to allocate resources and protect one user from another. That's why we have UID's, GID's, file permissions, read/write protection on address space, etc. If you want Windows, then by all means load Windows on your computer.
This is just another form of protection, it says, we don't want things to be executable in the stack space, just like we have a "noexec" option on the file systems. Yes, somewhere on the system you have to have a file system where exec is permitted, so an attacker presumably just use that space no? Same type of logic you are using.
The truth of the situation is, applications will never be bug free. This makes the exploit more difficult. Given the opportunity to make exploits more difficult we should sieze it. I understand fully that there are ways around it. But the more security layers exist, the less the likelihood of a successful attack. Particularly if all attempts are logged and someone actually pays attention to and follows up on those attempts.
Nothing is 100%, we all know that except maybe yourself. We are not deluded into believing otherwise, and I honestly don't think there is a significant likelihood that others will be.
I really would like to hear what Linus has to say on this directly, not only on this specific issue but on security philosophy in general. I really find it difficult to believe he would expect all applications to be free of exploits and all admins to have the time to personally audit each application and be 100% successful at finding any potential exploits in them.
But if that does happen to be his philosophical bent, then I would wonder if there isn't enough interest to start a whole seperate development thread for secure Linux. In fact, I wonder if such doesn't already exist given the widespread popularity of Linux, the importance of security, and the number of people here that reject any security enhancements to the kernel on the grounds that they might lull one into a false sense of security, religious convictions that userland code just should be 100% perfect, or concern that an additional CPU cycle or two might be wasted.
If it was proposed that this be the default I could understand the argument, but I really have a hard time understanding an argument over giving someone the option.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |