Why are we using priveleged images / state so much? (Was Re:

[paul () tdr com (Paul Robinson)]

From: Paul Robinson <paul () tdr com>
Organization: Tansin A. Darcos & Company, Silver Spring,
----
On Wed, 5 Jul 1995, Henri Karrenbeld wrote (Edited, where [ ] appears, for
brevity):

> Since Bugtraq is exceptionally quiet lately, I though I should make
> it come alive again with this discussion [ ] wu.ftpd [ ] allowing
> SITE EXEC access to /bin [ ] if in this /bin resides a program
> that gives access to executables outside /bin, but in the users
> reach [ ] this opens up a root vulnerability [ ] should have been
> set to /bin/ftp-exec and > which be set by the _PATH_EXECPATH
> variable [ ]


bt <bt () cyberflunk com> wrote:

> You have to run as root to setuid to the user, to open the log
> files, and to chroot (for anon) to the ftp dir.. of course after
> login, root privs are not really needed.

How about an explanation here by me, that seems to explain every single
security hole which compromised any system, that has ever existed:

   "You can't get blood from a turnip."

     - Explanation of why loan sharks routinely beat up their
       customers who do not pay and only resort to murder if
       the debt is uncollectable.  Fearful customers will find
       the money somehow if it is at all possible.  Dead ones
       can not, and won't.

   "A man cannot be made to tell what he does not know.  Neither
    the most brutal torture, the most subtle drugs, the exhaustion of
    sleep deprivation or any bribe, no matter how irresistable, can
    cause or allow a man to divulge that which he does not know."

      - Modified Slightly from one "Starship Troopers"
        by Robert A. Heinlein

   "A computer program that lacks priveleges can't get priveleges
    unless some process that has them, gives them to that unpriveleged
    program.  Period.   Full stop.  There is no way for a process to give
    away what it does not have, and there never will be.  It has to have
    something or access to it, if it is to allow someone else to have or
    access it.  Without priveleges, a program can do only what it is
    permitted to do, and no more.  No matter how skilled, how capable,
    or how talented a programmer the creator of the program is, you
    can't get priveleges where they are nonexistent.  I would think this
    would be self-evident, but apparently it is not."

    - Paul Robinson, "Why are we using priveleged images / state
                      so much?," June 6, 1995

It looks like people are making the same mistakes over, and over, and over
("Paul Robinson Presents The 'Energizer Bunny Theory of Programming
Errors': They keep going, and going, and going...:)), and not learning
from either history in general, or from the history of computing.  Maybe
this stuff isn't getting published, or maybe the people doing programming
don't do much reading of the literature, and maybe they don't do much
reading of books on theory and prior practices, or maybe some of the
people doing this work are not all that competent.  Or they don't care
much since they aren't being paid to do this work:

    "He said that he was a confirmed atheist, that no power on earth or
     method of torture could convince him otherwise.

    "I just wanted to show him his opinion was incorrect, so I took a
     'Busman's Holiday' and went to see him.  Within five minutes of
     arriving there, he swore on his knees in front of a video camera that
     he believed in John 3:16 and that Christ was his Lord and Savior.
     [description of sadistic practice deleted].  I was about to have him
     [deleted], but he had passed out by then, so I left.  Although I
     was a KGB Assassin, then, I didn't kill him.  Considering how cheap
     my former employers were, I wasn't about to do any 'freebies' if
     that is the correct word.  Lowers my market value. Professionals
     are supposed to be good enough at their work to be paid for it.
     Let amateurs kill people for free.

    "He later became a Catholic Priest.  And a damn good one, too!"

             - Vladimir Schrenkov in Paul Robinson's
               "The Gatekeeper: The Gate Contracts"


As far back as the 1960s people knew the dangers of running with
unnecessary priveleges.  Sometime during the 1970s or 1980s, I read a
book on operating systems design that said something like this:

     "When designing a system section to do a task that requires privelege,
      isolate all sections that require privelege to one area of the code,
      enable privelege only for the absolute minimum time needed to read or
      write or update whatever it is that requires privelege to do, then
      as soon as possible, drop priveleges and go back.  As little of the
      system should run in priveleged mode as possible."

I mentioned this to the administrator of a Univac 90/60 mainframe
(originally from the RCA Spectra Series mainframes, a slightly
incompatible clone of the IBM 360 and later IBM 370 when Univac bought
it).  He said that was exactly what VS/9 (Operating system which was far,
far better than anything IBM ever released) did.  It ran in user mode
except when it needed to domething priveleged.  It then invoked priveleged
state, processed the necessary priveleged function, then exited back to
user state, resuming at the next instruction after the request for
priveleged processing.

I refer to this as the "Get in, get it done, and get the hell out fast!"
theory of operating systems design.

You look at every major security hole that gave people ROOT priveleges or
other such things.  If there wasn't a way to get priveleges in the first
place, people couldn't have done things that way.  Let me make some
suggestions on how to fix the problem.

  1.  Don't have anything that is priveleged at all that runs directly from
      a user application.  Question: can a priveleged task change the state
      of some other task on the system, e.g. may process 14, a daemon running
      in the background, give process 9102 priveleges?  Or must that task
      (9102) be running a program which has setid root capability, e.g.
      the S bit in its execute value in the directory set?  If it can give
      priveleges to that task, let it do so for the exact minimum time
      needed and no longer, and possibly only exactly the priveleges that
      are needed.

  2.  Does a task need to do something directly or does it simply need
      something done by some task on the system?   That's not an idle
      question.  If I need to get access to a file, can I have the system
      temporarily put me into a special group, then temporarily grant me
      read (or read/write) access to the group that that file is assigned
      to which happens to correspond to the group that I am temporarily
      running under?  E.g. assign every file on the system that isn't a
      priveleged image additionally to group "95" and the only time a
      process is in group 95 is when it asks to be assigned to it, and
      is there for one O/S instruction only.

   3. Why does the FTP daemon need to have priveleges at all?  A user dials
      in via the FTP port (21?) on an internet connection.  The daemon sees
      this and spawns a process to run it.  Why is it necessary that this
      process log in at all?  Why can't the spawned process run as user FTP
      with, say, only the priveleges of user FTP? Have the spawning process
      (which might not need to be priveleged) log the access to the system
      log, and the spawned process, if it has to have access to the private
      unshared files of a specific user (non-'anonymous' FTP), issue a
      request to have its process name changed to that user, and the
      daemon that does that checks to see that user 'FTP' (notice I use
      capital letters, since 'real' logins on unix systems usually use
      lower case only, if I remember correctly), was asking for the
      service, it would know this was the Pseudo-user FTP which was
      asking for the request.  (Or follow the 'ps' program chain and
      see that the 'parent' of that task/process is the FTP daemon, or
      the Grandparent is the daemon spawner, which does run priveleged to
      spawn tasks under different usernames, or maybe IT doesn't have to
      either, since its username is DAESPAWN (also caps), and the same
      thing is done for it, etc.

   4. The login programs can be set up to automatically force a username
      to lower case when the name is accepted, and unless the job issuing
      the spawn is priveleged, a request for the Login service or spawn
      job under new username (if such exists), a username which is
      capitals is forced to lower case or it is set up to do so if it is
      requested by any task except task 1.  So only the initial task
      which starts the system is priveleged, only it can create
      priveleged tasks, and everything else runs nonpriveleged unless it
      requests privelege from task 1 or the O/S and is entitled to do so.

  5.  Force priveleged tasks to 'no error recovery'.  If any error occurs
      at all in a priveleged task, such as asking for a file that isn't
      there, or whatever, that error automatically forces the task to be
      unconditionally killed.  If a program needs to check for a file, it
      can request it from the system if it is running with the right to
      check that file.  When it needs to open the file, it can request
      a privelege to open that file or be handed the file handle already
      open from a priveleged 'file opener' task.  This would make trying
      to get a privelege by winning a race condition almost impossible,
      would it not?

  6.  Univac's VS/9 Operating System had the 'crtn' macro, which provided
      error recovery for any task on the system when it was running a
      program.  A nonpriveleged task could recover from the following
      conditions:

      -  warning (program interrupt (equivalent to 'fg' or 'bg' after ^Z on
         unix), shutdown quiet (operator issues '5 minute warning' before
         system is to be shut down), and task time overdraw (a user sets
         up a CPU usage check to stop from spending too much money if the
         task goes over so much, say, 2 cpu seconds).

      -  critical (Program check (invalid opcode), Priveleged
         Instruction, Invalid Supervisor Call,  Subsystem failure
         (a subsystem was like a DLL in Microsloth Windows, a shared
         program used to provide services to other programs and could
         be used in place of logging on to a username), and the
         Terminate Program macro.

      -  Fatal (any critical error occurring while handling a critical
         error).

      Warnings occurring during critical or fatal handling are ignored.
      A critical error could be caught and recovered, returning to any
      point in the program.  A fatal error allowed the program to shut
      down, it had to terminate within 5 minutes, but 'terminate' also
      included the privelege of issuing an 'execute' to another program,
      which could be this program itself, allowing it to restart itself.
      Critical or fatal errors during fatal recovery caused immediate
      forced task termination without further recovery.

      The manual said it precisely:  "This macro is designed to give a
      nonpriveleged user program the maximum possible error recovery
      capability while still preserving system security."


  6.  Think about how often are jobs left running with constant
      priveleges when they need them once during the start of the job, and
      maybe once at the end?  Too often.
      DEC VMS and CDC Cyber implemented the equivalent of the "Access
      Control List" where a file or group of files can be permitted to a
      user or several users, and Cyber even automatically logged every
      access into a private file for the owner of that file if they
      requested that all access to it is to be logged, including when,
      what was done, where it was done to the file, and whose user name
      did it, even if the file was publicly readable / writable.  ACLs
      and access logging are separate features usable together or
      independently.

  7.  I know how priveleges are made available and provided on the
      Univac VS/9 O/S and IBM 360/370/3xxx/Sierra Mainframes, plus the
      Music Operating System on that machine series, the PDP-11 series
      from the 11/23 and up including the RSTS/E O/S that ran on it.
      I also know of a few other machines and operating systems.  Plus
      how protection has been available, but almost never used, for the
      Macintosh and the Intel 286, and 386/486/586/P series machines,
      because the O/S routinely almost never uses it.  Microsoft Windows
      is so woefully deficient in this ridiculously minor-to-implment,
      and trivially simple major security feature that it just makes me
      want to puke.  Device drivers need I/O priveleges for the devices
      they run AND NO OTHER PRIVELEGES.  Writing to user memory can be
      done by a special priveleged task when needed, or the memory area
      of the user's buffer can be elided to by overlaying a new descriptor
      giving the device driver read/write priveleges on that user's
      memory space in that area, and only that area.

  8.  I believe I am being reasonable in my expectations.  I do not think
      it is unreasonable to see if there aren't ways to reduce the number
      of places that a system must run in priveleged state to as few as
      possible, and as near to zero as it is capable to set.  Programmers
      stay in or enter priveleged states too often because it's a easier
      to stay priveleged than to only activate priveleges when needed,
      and to drop them immediately when not needed, or never permit
      priveleges and only use request for service messages for specific
      features, which can be set up to provide those services only for
      the time needed to do what is necessary.

  9.  Nobody says we have to slow down user programs, we can find ways to
      only use priveleges when absolutely necessary.  Perhaps, during
      initialization, all priveleged functions (opening a special private
      file, opening a port on the network, or whatever) can be activated,
      then the process can permanently drop all priveleges since it will
      no longer need any priveleges (I am assuming that if you do
      something such as open a file when priveleged, that you would not
      normally have access to that file when not priveleged, that the
      open and read/write capability to that file remain even if the task
      permanently and irrevocably dismisses its priveleges.

If stuff like this had been done, I think the number of accidental root
or priveleged access holes would be reduced to maybe 1% of what they have
been.

Hmm.  Why does ROOT even have to be on the system as a user account?
There are some things people have to do as root, but why not request
special programs (like 'Shutdown') or other features, to be set up to
allow only users in a certain class or certain userid to do them.

For example, the only user that can do a shutdown is user SHUTDOWN, their
login shell is a procedure that asks some questions that only admin
people could know, and if approved, runs the program(s) to begin an
orderly shutdown.  Emergency shutdown can be done from any admin account
in the correct group, and/or only certain users, perhaps special
priveleges.

There are other ideas that might be even better.  Let's just ask, does
something need privelege to do this, can we get in, get it done, and get
the hell out fast?  What other options do we have besides staying
priveleged constantly?

We do not want ask "Will this code need priveleges?"  What we want to ask
is, "Must this code have priveleges, why and when, and if so, how can we
make that priveleged state as short a period of time as possible?"


I would love to hear questions, new ideas, or comments.  Privately or to
the list.

Paul Robinson

--





Find out about "The Gatekeeper: The Gate Contracts" - Write to address below.
Paul Robinson - paul () tdr com / tdarcos () MCIMail com / tdarcos () access digex net
"The Greatest Philosopher in the World, maybe the Greatest who ever lived."


---
The following Automatic Fortune Cookie was selected only for this message:

Rules for driving in New York:
        1) Anything done while honking your horn is legal.
        2) You may park anywhere if you turn your four-way flashers
           on.
        3) A red light means the next six cars may go through the
           intersection.