Re: libresolv+ bug

[tqbf () rdist org (Thomas Ptacek)]

> Hardware-protected memory on both ends of every buffer and between
> the return address on a stack frame and the current function's automatic
> variables would be good for security purposes.  That way most simple

[ much, much detail omitted ]

All very good, interesting, thoughtful solutions, and I appreciate the
information, but it doesn't address the point I'm bringing up.

The primary problem, as I see it, is not that SUID programs are being
written poorly, or that the sensitivity of SUID programs is not being
adequately dealt with by the operating system, or the compilers that
produce the executable code; it's that SUID programs, as present in most
modern Unix operating systems, are being written at all.

You'd figure that at this point, we'd realize that one of the primary
security issues we're dealing with is that Unix operating systems overload
UID 0 hideously, in most cases opting to give any program that needs
anything beyond normal user privileges full root access.

Beyond that, no Unix OS I know of allows admins or programmers to reliably
specify privileges in anything more than an "all or none" fashion - if
your program needs permissions to write to /etc/passwd, you need to let it
run /bin/sh and write to /root/.rhosts as well. I think it's been
adequately demonstrated to us that the POSIX saved credentials solution
insufficiently addresses the potential for subversion most SUID programs
have.

Instead of talking all day about how we should prevent security problems
by patching individual security holes, both entirely and, on a
program-by-program basis, piecemeal, as those holes are revealed to us, we
should be discussing how to provide programs with enough privileges to do
their job, and nothing more. Unfortunately, none of the solutions we've
got out-of-the-box and on the net address "least privilege" adequately.

It seems to me that this is an easier (and more worthwhile) problem to
solve than "how we can best align memory to force buffer overflows to
cause memory faults", which, although a very worthwhile issue in and of
itself (which would probably save lots of programmers a lot of grief in
the debugging process, as well as enhance security), doesn't do enough to
address the broad range of problems that exist in SUID and daemonic
programs.

Regardless, I'll spare the readership of this list another holy war, and
agree that you've got good points. Some of us have some tricks up our
sleeve that we'll key y'all into when we've got the wrinkles ironed out,
but I'd just like to toss the idea out to you that there's a pretty strong
chance that we don't yet know everything we can subvert in an SUID
program, and that resolving buffer overflow problems (as we know them) is
really just one more band-aid on an inadequately expressive security
system.

[ as an aside... ]

> 1.  A general-purpose setuid program that acts as a switching point for
[ elided ]
> 2.  An interface script written in a language that handles its own memory
>     allocation, like perl, or even GNU flavors of sed and awk; tcl would

Something to consider: I'm guessing that the reason everyone didn't
instantaneously know about the 'suidperl' program, the minute that
the program was brought into the afflicted operating systems, is that
none of the people that normally run through source code finding bugs
wanted to read 'perl'.

The idea of allowing an interpreter for a language like perl (which I
like, don't get me wrong...), swiss-army chainsaw that it is, to run with
privilege, given the size and complexity and potential for weird
interactions with that code, scares me greatly. It'll never happen on an
operating system that I run, and I know that at least a few people out
there agree with me.

[ as another aside, which more directly supports my first point... ]

>         - binding to privileged ports (call bind(), drop privileges, exec
>                                        child; inndstart does this with innd)

Bad!

We're talking about problems (in this specific instance) in free, open
operating systems, in which anyone can go tinker around in the kernel and
fix whatever it is that concerns them.

Why would you continue forcing programs to run as root, just so they can
do something as trivial as binding to a privileged port (the concept of
privileged ports strikes me as one of the worst concepts ever introduced
into Unix networking code), instead of hacking your kernel so that some
other UID or GID can do it instead (say, anything running as UID "netpriv"
or GID "network"), thus eliminating any real concerns of far-reaching
security programs in a whole ugly host of user-level networking programs?

-----------------------------------------------------------------------------
Tom Ptacek at The rdist Organization / exit(main(kfp->kargc, argv, environ));
------------------------------------------------[ tqbf () rdist org ]-----------
"If you're so special, why aren't you dead?"