Request for discussion.

[newsham () aloha net (Timothy Newsham)]

Hi,

  I drew up a list of some things I've been thinking about recently.
I would appreciate it if some of you would read it over and tell
me what you think about them.  Right now its a very rough outline,
I didn't bother checking spelling, dotting all the i's etc.
Some of the ideas are probably unrealistic (as far as unix is
concerned) while others could be done (and some are being done)
today.

                                 Tim N.

-----

scope of discussion
-------------------
 attacks considered:
  network user without local account running services on local machine
    as priveledged or unpriveledged user or creating/altering/reading
    files on the filesystem as priveledged or unpriveledged user.
  local user changing from his user id to the id of another user
     or reading/altering/creating files as another user.

priveledged programs
--------------------
trusted programs 
  run in roots .cshrc,.profile,.login,.logout, etc.
  run in a cronjob
  run from system startup
  run from inetd
suids

Changes
-------
- run network daemons with lower priveledges.
discussion:  Why are so many net daemons run as root?

- collect suid programs into common directory, or perhaps
  a seperate directory for uid/gid. (both in src and bin form).
rationale:  Increase awareness of security critical programs.
  Make it easier to check all suid programs at once.

- collect daemons into common directory (done already - /usr/libexec in bsd).
rationale: see above.

- database of priveledged programs and dependencies.  Ie config
  files, temp files, directories, databases, etc.
rationale:  Keep track of assumptions in security critical programs.
  Avoid holes that arise out of changing an assumption (example
  making utmp world readable).  Make it easier for automated
  checks (ie. world writeable directories like preserve and
  msgs).

- per-process "trusted users" information.  Only run binaries owned
  by a trusted user.
discussion: simple way to do this is to put this functionality 
  in the shell.  To be really effective the functionality would
  have to be in the kernel exec code.  This means the process
  structure (or maybe the credential structure) would have
  to have a uid list of trusted users.
rationale:  reduce the risk of trojan horse attacks.

- non suid binaries owned by bin.  bin considered priveledged.
  ie nfs remaps bin as well as root.
rationale:  better organization.  Remove some of the "root clutter".
  offload as much as possible from the root uid.   
discussion:  This might not be a good idea for the "trusted" binaries
  since root will run these files thus making bin equivalent to root.
  (As for nfs,  nfs needs finer controls anyway).

- system list of users allowed to use suid and sgid.  Suid
  binaries not run if file owner not allowed to use suid/sgid.
rationale:  reduce the ability to store priveledge on a filesystem.

- secure network services.  authentication and encryption.
  point to point encryption in socket layer?  Change
  services that rely solely on addresses for authentication to
  rely on additional or other information.  Replace
  the priveledged ports model.
discussion:  To replace priveledged ports a "trust" server could be 
  setup.  This server would be on a well known port which would be
  hard to get.  Trusted hosts can be done away with or complemented
  with private keys (one set of keys per "trust") or a public
  key system (one secret key per host). 
rationale:  lower the risk of passive network attacks.  Decouple
  network priveledge (packet filter access, "priveledged ports")
  from root priveledges.

- finer grained priveledges.  ie. net -> raw sockets, priveledged
  ports, etc.  rlogin,rsh,etc become suid net.
    net - raw sockets, priveledged ports, packet filters, routing tables
    console - console and keyboard device.  X servers.
    fs - quotas.
    uucp - modem
    kmem - read kmem
rationale:  Priveledged programs run with least priveledge required.

- uid/gid passing over sockets.  Library functions to make
  passing uids, gids and fds easier.  Support for multiple
  uids per process (there is already uid, saved uid and effective
  uid).  Ability to disable and reenable any of the uids.
  (This can be done more effectively with a bitmask than
  having a seperate "saved uid" variable).  Ability
  to specify how priveledges get inherited (maybe not necessary).
rationale:  Add flexibility to security model.  Make security
  features easier to use.  Move closer to a capabilities based
  system.

- program to run a process with a lower priveledge.  Run
  programs in startup,cshrc,etc with minimal priveledge.
  Database of programs/priveledge requires that would
  be used by shell to lower priveledge before running
  certain programs.
rationale:  Programs run by a priveledged user don't
  always need priveledge.  Run with least priveledge.
  Reduce the risk of trojan horse attacks.

- capability based security model.   Passing of priveledges.
  Ability to create new capabilities with a subset of
  a capability as in VSTa.  Disabling of priveledges.
  Multiple priveledges per process.  Security server for
  giving away priveledges to certain programs (is this
  possible to do in a secure way) to replace suid/sgid.
  Security server for requesting priveledges.
rationale:  Finer grained security model.  Run programs
  with least priveledge required.  Reduce coupling
  of filesytem security with system security.  Support
  the transition from host security to distributed
  network security.