Re: linux-kernel-digest V1 #4990

Robert Dinse (nanook@eskimo.com)
Thu, 30 Dec 1999 21:57:01 -0800 (PST)


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/