lkml.org 
[lkml]   [1998]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.059 / U:1.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site