Messages in this thread | | | Date | Fri, 7 Aug 1998 23:18:12 -0400 (EDT) | Subject | Re: Stack Smashing and no-exec | From | (Kragen) |
| |
On Fri, 7 Aug 1998, Jon M. Taylor wrote: > On Fri, 7 Aug 1998, Kragen wrote: > > On Fri, 7 Aug 1998, Jon M. Taylor wrote: > > > As long as Linux is a traditional monolithic Unix-like kernel, I > > > think this is a reasonable attitude to have. Linus is correct. The suid > > > root programs should be fixed. If that task is difficult, use bounds > > > checking or whatever you need to be able to fix the problems. > > > > I think some kind of small-interface solution like bounds-checking > > compilers should help considerably -- but, of course, it's not a > > panacea. > > Right. The point is that the primary responsibility must lie with > the suid root code. The kernel can help catch these bugs, as can various > other tools like the compiler, but ultimately the code needs to be fixed.
No, that wasn't what I meant. If you have a compiler that does bounds-checking in a reliable fashion, you may indeed be able to avoid adding features to the code to make sure it doesn't buffer-overflow. In fact, you might be better off that way.
What I meant was that there are (many!) other security bugs that are not the result of wild pointers, and so you can't rely on your compiler to catch them.
> > Lots > > of things are setuid root so they can bind a reserved port, for > > example. I'll be a lot happier when I can run named as a normal user! > > Would this be done, or would you have a user that has the > additional priv of being able to bind to that specific port? That is, > would capabilities be bound to a specific user like group membership is > now? Or would capabilities be bound to a group instead?
I think capabilities are per-process, not per-group or per-user. Is there a Linux-capabilities FAQ, anyone?
> Also, how would > these capabilities be defined? Would there be categories and/or any sort > of hierarchy to subcategorize the set of all possible capabilities, or > would it just be one long list of stuff, each capability standing alone?
It's a long list of stuff (less than 32 at the moment, I believe) that mostly has to do with things only root could do in the past.
Kragen
- 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
| |