Messages in this thread | | | Date | Fri, 7 Aug 1998 16:30:04 -0700 (PDT) | From | "Jon M. Taylor" <> | Subject | Re: Stack Smashing and no-exec |
| |
On Fri, 7 Aug 1998, Kragen wrote:
> On 7 Aug 1998, H. Peter Anvin wrote: > > No it cannot (unless there is a kernel bug, of course.) The problem > > occurs with poorly written setuid programs or as-root-running daemons, > > where an unprivileged user manages to inject data that somehow causes > > the privileged program to take an unauthorized action. > > You say "poorly written". The trouble is, essentially all setuid > programs or as-root-running daemons are poorly-written enough to have > buffer-overflows in them. The only one I know about that hasn't had > them yet is qmail-lspawn.
I'd say the basic question is this: Are suid root programs to be considered in effect part of the OS, or are they just userspace programs with more privs? In the first case, you'd treat them like device drivers and fix them so they can't stomp on anything. In the second case, though, you'd have to say that userspace should not ever, under any circumstances, root privs or not, be able to break the kernel.
It appears that the first case is the attitude of Linus and many others. It is in line with the traditional Unix "root is God" attitude. If you are running programs with the same priv level (in effect) as the OS, you'd better not count on the OS to save your butt if that program falls over. It may try, but no guarantees. Similarly, the kernel will try to continue after an oops, but that is not guaranteed either.
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. Debugging device drivers can be difficult too sometimes. All you can do is your best, but I'd hope you would be willing to put forth a bit more effort to ensure that something with root privs is clean.
I think this situation is a very good argument in favor of ACLs. Root is too blunt an instrument. It creates "implicit microkerneling", where any special priv needs require the needy code to in effect become part of the OS. Windows .DLLs do this, and it creates massive stability problems. We do it too, or we wouldn't be having this discussion. And as long as suid root code is in effect part of the OS, it should be held to the same standards.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- 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
| |