Re: Public disclosure of discovered vulnerabilities

From: Jon A. Solworth (solworth_at_cs.uic.edu)
Date: 06/09/05

  • Next message: Bryan Olson: "Re: Public disclosure of discovered vulnerabilities"
    Date: Wed, 08 Jun 2005 23:15:53 -0500
    
    

    David Wagner wrote:
    > Jon A. Solworth wrote:
    >
    >
    > On today's machines, they are all critical. In today's commodity
    > systems, the wall between root and non-root processes is a sieve.
    > If you can get access to a non-root account on a Unix or Windows machine
    > (for instance), you can usually get access to root, too. While it is
    > probably possible to configure machines to prevent nonroot->root privilege
    > escalation without impacting usability, this seems to be highly non-trivial
    > and today's systems don't seem to meet this bar.

    If this is true, then perhaps we are working on the wrong problem. This
    means that the whole machinery for protection including architectural
    support, OS design, and the authentication mechanism is esentially
    useless if you can create or install an executable, as you can in most
    systems to which you have access to a shell.

    >
    > And even if you can prevent nonroot->root privilege escalation, a
    > buffer overrun in your web browser is pretty serious. The web browser
    > handles a lot of sensitive information.
    >

    I think the web browser, as currently constructed, is a terrible idea
    as is any monolithic application. I compiled a few browsers from
    source, they contained as I remember a few hundred million bytes of
    source and an almost 2 GB build. Good luck on securing it.

    > And even if you can prevent nonroot->root privilege escalation and
    > can secure your web browser, this won't be enough to stop worms and
    > viruses. Worms need only enough privilege to be able to access the
    > network; thus, all processes (root or otherwise) are potential worm
    > infection targets.
    >

    Of course, an arbitrary program doesn't need net access. The DAC
    model is, IMHO, not sufficient for today's threats.

    >
    >>I think that
    >>the vast majority of problems in 4 and 5 can be handled with
    >>appropriate authorization models (i.e. access controls ).
    >>Disclaimer: one of my research areas is authorization models.
    >
    >
    > I've done work on this (see my work on Janus). It seems plausible
    > but non-trivial. Some of the leading systems-building projects I can
    > think of in this area are Systrace, SELinux, Polaris, and many others,
    > but none of them are far enough along yet to do what we need, I think.
    > But I completely agree that it is a very promising direction and worth
    > pushing on a lot further.

    Of course I know about Janus. And yes, I was not talking about what
    exists but in the direction I think we need to move. We are
    implementing a new authorization model in Linux called KernelSec, but
    while we have quite a bit of it done, its not complete. And even when
    its complete, it would be foolhardy to use it in a production setting
    until it is hardened.

    >
    >
    >>I think an authorization approach is complementary to correctness
    >>oriented approaches since each has at its heart the goal of reducing the
    >>complexity of the trusted computing base.
    >
    >
    > Definitely. Indeed, if I had to pick only one direction, I'd probably
    > pick "reducing the TCB" as more important than "improving the language".


  • Next message: Bryan Olson: "Re: Public disclosure of discovered vulnerabilities"

    Relevant Pages

    • Re: r command security
      ... > system administrators didn't buy into this because they have to use these ... > features to work on different AIX machines and request me to further ... webserver and is only ever logged into by root for mounting disks with ... If a trust relationship is ...
      (comp.security.unix)
    • Re: FC9 Compromised...
      ... of time before they get root. ... should be aware of the likelihood that these machines have keyloggers ... Get your data off via the rescue disk boot, them completely wipe and re-install you compromised machines. ...
      (Fedora)
    • Re: how to access remote CUPS printer?
      ... On the remote machine, FC5, I am root. ... Is there a nonroot IPP client that can ... which consists of a single FC5 box. ... The automatic browsing only works for machines on the same LAN. ...
      (Fedora)
    • Re: file system setup for new system - recommendations?
      ... I will start over and rebuild the system ... machines on my LAN. ... > /var in root, there's a discussion of the relative ... "I would be able to backup directories (or ...
      (freebsd-questions)
    • Re: What are these for?
      ... Only root can read the logfile. ... it decreases security instead of increasing it. ... Starting/running a web browser is a security relevant task. ... security risk and because emacs could display and modify files that ...
      (Fedora)