A possible way to make the argument in your thesis about security...
Jonathan S. Shapiro
Sun, 25 May 1997 16:46:38 -0400
[eros-arch: I am forwarding this because others on the list may have
useful comments, and in any case the discussion may be interesting.
Jonathan Smith's original comments can be found at the bottom.]
Re your comments on capabilities v/s ACL's... what you say is true,
and potentially very useful, but in large measure not relevant to the
kinds of security questions that we are commonly interested in asking.
We are interested in making a priori (i.e. static) demonstrations
about the dynamic behavior of programs. That is, we are concerned
with what actions are *possible* rather than what actions are actually
performed. This precludes the execution of programs that are
potentially insecure but do not exercise their holes; in this sense,
such a demonstration might be considered unduly conservative.
Because we are making a static demonstration, we are concerned with
establishing the *possible* authorities of the program, and showing
that they satisfy some constraint. The possible authorities are the
reflexive transitive and symmetric (if program A can and does talk to
B, program B can subsequently talk to A) closure of the initial
Taking the table model as a starting point, there are two differences
between ACL's and capabilities:
1. The initial set of authorities -- what you call the actual
authorities -- is generally viewed as much smaller in a
capability system. This is misleading, for reasons I shall come
to in a moment.
2. The initial set of authorities in a capability system is closed
provided that no third party holds controlling authority over
the process. By this I mean that there exists no party having
the right to alter the capability registers of the process in
question. In EROS, this is generally assured by construction.
3. In a proper capability system, no process holds intrinsic
authority to a shared name space. This is a necessary
precondition for suitably constraining the intersections of the
reachability graphs of two programs.
It is the third point that is the salvation of capability systems. In
reality, a UNIX open file descriptor is a capability. In order to
exercise the authority conveyed by the ACL, the process must first
contrive to have an open file descriptor to a suitable directory.
The true problem is that all UNIX processes implicitly hold an open
file descriptor to the directory '/' (it is, obviously, not
implemented this way, but this is a fair simplification for
exposition). This means that it is impossible in practice to isolate
the name spaces of the programs, and therefore impossible to establish
proper constraints about the intersections of reachability graphs.
Another salvation lies in (2), in that the chmod(2) operation may
change my access rights even if you don't have authority over me. This
is mostly a manifestation of the shared name space problem.
Now in writing that down, I realized that you could get very close to
fixing UNIX by the following means:
1. Build a version of exec(2) that takes initial CWD ('.') and ROOT
('/') as arguments.
2. Add an ACL to every directory entry. The authorities conveyed by
a call to open(2) are the intersection of this ACL plus any ACL on
the inode. But for backwards compatibility, the inode ACL can be
3. Place ALL name spaces in the file system. The big current
offenders are the PID/PGROUP name spaces and the shared memory
object name spaces.
4. Revise all current operations on the name spaces in (3) to be
implemented using suitable file operations.
5. Optional, but highly desirable, let processes act as fault handlers
for directories and files. This allows name spaces to be lazily
constructed, which is important for performance, but probably
requires persistent processes.
Under this model, plan 9 gets pretty close. The only thing missing is
the per-directory-entry ACL.
The problem with this model is that the per-dirent ACL's have to be
thought out very carefully in order to ensure that my chmod(2) cannot
increase your authorities.
In message <E0wVdmn-0000oQfirstname.lastname@example.org>, Jonathan Smith writes:
> A friend of mine, Simon Crosby, has written up a nice set of lecture notes
> on operating systems. I'll begin by summarizing a nice way
> to differentiate ACLS and capabilities from Simon's notes.
> As we know, rights can be represented with an "Access Matrix", which is
> a matrix of subjects v. objects.
> Subjects: users (by uid); executing process in a protection domain;
> Objects: files, devices, domains/processes, message ports
> Since this matric is LARGE and SPARSE, two common representations are:
> 1. by object: list of subjects and rights stored with each object
> => ACCESS CONTROL LIST
> 2. by subject: store list of objects and rights with each subject
> => CAPABILITIES
> Shap - here is my suggestion:
> For an EXECUTING process, the second representation should be
> be much more compact, as it reflects ACTUAL rights rather than
> POSSIBLE rights. As long as the number of processes in the system
> as a whole is not unreasonable, the number of true things we must
> know for the system to be secure should be much less.
> QUANTIFICATION: your job, but perhaps doing an estimate from
> a local server like dsl.cis would give you an estimate for:
> - scale of access matrix
> - scale of ACL for this matrix
> - scale of Cap. representation for active processes?