Re: A possible way to make the argument in your thesis about security... Jonathan S. Shapiro (shap@eros.cis.upenn.edu)
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.]

Jonathan:

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 authorities.

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 dropped.
  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.

shap

In message <E0wVdmn-0000oQ-00@heaton.cl.cam.ac.uk>, 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;
> combinations
> 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?
>
>
> -Jonathan
>
>
>
>