Ideas Summary (3/3)

This is a summary of ideas from a email discussion between Dave Hudson
and myself. (Part 3/3)

This contains two major topics:

4 - Security IDs
5 - Misc Ideas

[4 - Security IDs]

Objective:
   - We want the fine-grained hierarchial security of VSTa,
     but we also want good user-definible group capabilities. (i.e.
     something better than letting users hold 6 ids which are still
     sysadmin created)

Main Ideas:
   - Make each process have only *ONE* security id (their active ID)
   - Each process will also have a UID will will be their primary
     security id (i.e. the one they start with). It will, however, have
     nothing to do with "security".
   - Try and make id forging automatic for users (for if it's not
     automatic, they probably won't use it)
   - setuid should no longer be necessary, a correct client/server
     design, with a server started with the correct permission is the
     more secure way
   - Allow an id to have a list of "equivilant ids" which should act
     AS that id. These lists will be dealt with and checked by an ID server.

Security ID specifics:
   - Process specifics
     - a process has a "UID" and a "security id"
     - in a "user" oriented example: WHen a user logs in, his UID and
       security id will be the same. (usr.dave for example). When he
       forges to "usr.dave.bin", his UID will remain "usr.dave" for
       identification purposes. Once a process forges lower, there is
       no way to go back, and since one can't hold more than one ID
       (even inactive), it truly is a ONE WAY street.
   - ID Server
     - after a match of a processes security ID to the resouce ID fails
       the ID server will be asked to do a check of alias lists.
     - because the aliasing is strictly a "resource ID->real ID"
       equivilancy mapping, there is NO need to be able to give
       OTHER users ids. All the information about which other ids can
       access a particular id domain is stored INSIDE that id domain.
       (i.e. easier to make secure)
     - effectively most of the security code is moved out of kernel-space
       and into server-space.
   - "Equiviland id alias lists"
     - These "equivilant id" alias lists could have a "access mode mask"
       which says which access modes people in the list are CAPABLE of
       getting. This mask would be combined with the access mode of the
       resource they access to determine their access mode for the resource.
     - if the equivilant id alias list has CHMOD access in the "access
       mode mask" then users in the list will be capable of administering
       the id domain in the id server.
     - The id server will allow appropriate people to administer the
       name<->id mappings and equivilancy id lists for an id domain.
       (either by the CHMOD condition above, or the REAL holder of the id)
     - If a resource has an id "usr.joe.group.1" and a process has id
       "usr.dave", which is being checked for access, EACH level of
       "usr.joe.group.1" will be check for an alias list, and each such
       list will be checked for "usr.dave". The process will be granted
       the access modes associated with the SHORTEST alias match of
       "usr.joe.group.1" (if any).

[5 - Misc Ideas (Summary)]

These two ideas sort of look at the same issue. What to do with
common code between servers which one dosn't want "duplicated" and
"compiled in" to the servers. (Ex. TTY code, partition code, whatever)
 - Boot time shared libs
      - Dave Hudson feels this is not very difficult, and thus a
        definite option. It would also allow better performance than the
        relay() option for most (all?) cases. However, there are some
        drawbacks to having something be a shared lib instead of a server.
 - relay() style message passing
      - This entails allowing a server to get the message arguments
        without the data to check and see if it actually cares about the
        data before it's mapped into it's space. It should then be able
        to pass the entire message on, including data, to another server.
        Many "in-line" servers could be handled this way.

Security Related:
 - It would be nice to have some mechanism for determining if a
   given message connection is "secure" from end to end. Since "everything"
   can never be secure, one good way to keep a system as secure as possible
   is to allow servers/applications to know whether connections are secure
   or not and act appropriately. After all, if the sysadmin chooses to allow
   dangerous transactions over a non-secure connection, at least it's his
   choice.
Received on Wed Aug 9 12:23:20 1995