Re: libresolv+ bug

[dichro () tartarus uwa edu au (Mikolaj J. Habryn)]

> > > > > "TP" == Thomas Ptacek <tqbf () rdist org> writes:

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

  absolutely. for some reason, there is a distinct lack of
appreciation of the two issues. privileged code that is badly written
can and will be exploited. but containing that (inevitable) damage
seems to get very little attention - perhaps because it's so difficult
to do well on traditional unix systems.

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

  and indeed, many people do wind up doing this. though it could be
improved still further, given a more flexible system (and the time to
write it :). why does a network daemon (inetd, say) need privs to
write to disk (beyond logging)? restrict your mail daemon uid to allow
bind()s only to port 25 or > 1024. if someone compromises it, sure,
they'll be able to intercept incoming mail. but, they won't be able to
intercept incoming interactive sessions and capture passwords. and so
on. of course, setting up this level of restrictions is time
consuming, and fairly complex - but it would seem well worth it.

  i've been toying with the notion of doing a completely abstract
implementation of this for a while now. something where you can build
a directed graph of access levels, then attach privileged operations
to them arbitrarily. for extra points, make it dependent on the
context and arguments of the operation. for still more credit, do it
without needing to add a pcode interpreter of some kind into the
kernel. a simple implementation wouldn't be particularly difficult - a
basic graph handling package with rapid functions to determine whether
a given node is 'above' another or not... then go through the kernel,
and gradually convert all the suser() (or whatever your local
equivalent is - i'm most familiar with linux) calls to queries to the
new engine. since nobody's done it yet, it's probably a lot more
difficult than it appears to me. or has it been done?

  how do systems like trusted solaris, etc. and the MLS ones present
themselves? ie, how much flexibility do they give to someone trying to
provide only a minimal set of privileges?

m.