Aucbvax.4571
fa.unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Wed Oct 21 03:06:44 1981
Why one does NOT want access lists (in files).
>From walton@LL-XN Wed Oct 21 02:35:50 1981
There are at least two kinds of file protection system.  One, which I call
the work oriented one, associates a single lock with each file and a list
of keys with each process.  It aims to ensure that people get their work
done smoothly with little bother from the protection system.  The major
sin in this philosophy is for a legitimate user to be thwarted by the
protection system: so the emphasis is on making sure that everyone who
needs a key has it, without going overboard.

The other, which I call the security oriented one, associates one user id
with each process and a list of user id's with each file.  This is
appropriate to a real security system with strict monitoring of file
access, with only users with a need-to-know having access, etc.
The last thing you want to do is group users together in such a system.

The latter system is what I think of as an access list system, like
something Ken Thompson talked about adding to UNIX years ago, with
an access list for each file.  MULTICS apparently has such a system.
I suppose the former system might also be called an access list system,
but I am not used to it being called such.  Do not know quite what
to call it, frankly.  A lock-and-key list system maybe.  The idea
is that the locks are dumb, like real world locks, whereas a file
access list is a smart lock.

This latter system is not that appropriate for UNIX, except for KSOS, NSA's
attempt to make a version of UNIX suitable for use in a real security
environment.  Its too easy to lose control of security in other ways
in UNIX.  The first system is work oriented because it is easier
to maintain keys than locks, since each user deals with only one user
but many files, so a system with dumb easily maintained locks on the
files and smart lists of keys is easier to work with than a system
with smart locks and dumb keys.

I have an interesting hypothesis to the effect that there is no real
use for a system that maintains a list of group id's with the process
and another with the file's and attempts a full matrix match.
I.e., it is sufficient to have smart keys interacting with dumb locks
and smart locks with dumb keys, but not have any interaction between
smart keys and smart locks.

Of course everything is an efficiency matter in the end, since either
of the above systems can be used to emulate the other, but with such
poor efficiency and bad user confusion that one would not want to do it
very much.

I find this is my third missive on this subject in a few days: one
proposal and two responses.  I am going to try the combined strategy
of accumulating public responses and responding in appropriate cases only
to individuals in order to reduce this rate.  Unfortunately, while
proposals in this area are often simple, analysis of the requirements
placed on such a system is not, so I hope the rest of you will
tolerate me if I invite debate for a little while longer.

-----------------------------------------------------------------
 gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org>
 of http://communication.ucsd.edu/A-News/


This Usenet Oldnews Archive
article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 
 Bruce Jones, Henry Spencer, David Wiseman.