Messages in this thread | | | Date | Fri, 7 Aug 1998 16:21:50 -0700 (PDT) | From | Tracy R Reed <> | Subject | Re: [PATCH] [SECURITY] suid procs exec'd with bad 0,1,2 fds |
| |
On Fri, 7 Aug 1998, Linus Torvalds wrote:
> Yes, it may be harder, and yes, it may take longer, but you're assuming > that the kernel patch is somehow a fix for the bug, and it isn't. It's at > best a bandaid.
I agree with this much, absolutely. But buffer overflows will always be there. After 10 years they have not been stamped out. Lazy coders or not, I have to rely on some of this software. This means Linux (and other unix's) will always be vulnerable. If we can't fix the kernel, and we can't fix the applications (as proven by 10 years of examples) we're all kinda screwed. I hate to be such a fatalist, and I'm sure some sort of solution will be attained someday, it's just a bit unnerving to think there's nothing that can be done for such a simple problem.
The kernel/hardware protects the system from bogus code via mechanisms such as memory protection. This is quite useful and makes the system much more stable. Now if only we could find a way to make the kernel/hardware protect the system from other forms of software error (such as buffer overflows) we would be much better off.
> Quite frankly, I'd personally be much happier with having a few systems be > "rooted", and get the application fixed properly as a result, than have > some bandaid that _almost_ fixes the problem.
I'm sure glad my boss isn't reading this thread. That Linux firewall I've installed could get me into trouble.
> The thing is, that if there are known exploits (the ones floating around > in the hacker community), there is _no_ excuse for not fixing those bugs. > As a result, there is _no_ excuse for having a system that is vulnerable > to being rooted by old and known exploits.
Quite true. Unfortunately, this turns my companies security into a race between me and the hacker. I check bugtraq every day. But if someone in Europe gets up before I do and has their way with our network, I'm in trouble.
I would really like to see something like the Stackguard system implemented in one of the major distributions. It would be a great selling point for them. Any program which is suid, runs as root, or otherwise needs to be trusted could be compiled with stackguard, leaving the rest of the non-trusted programs running at full speed. It's a userspace solution which does the job and could really improve the image of Linux security-wise. Being open source buys us peer-review but it also buys us more exploits than any other OS simply because of ubiquity of the OS. This gives us an undeserved bad name. The Stackguard method still crashes the program, encouraging users to report bugs and maintainers to fix them, while allowing a fail-safe mode of failure.
> personally think that it is a bad thing to have in the kernel, and I won't > accept it in the tree _I_ maintain until somebody can come up with better > arguments than I've heard so far.
At least you are open to the possibility that someone may some day come up with a better argument. :) Overall I think I agree that I'd rather not have this sort of thing in the kernel and would love a userspace solution but it becomes a choice between the lesser of two evils. If it takes 1 month for adapted exploits to start showing up, that's a month during which my machine is far less likely to be broken into. I haven't applied the patch yet but it's tempting.
-- Tracy Reed http://www.ultraviolet.org Windows is the one true OS. MS invented the GUI. MS invented the 32 bit OS. MS is open and standard. MS loves you. We have always been at war with Oceana.
- 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.altern.org/andrebalsa/doc/lkml-faq.html
| |