[cap-talk] Non-safety vs. permission propagation -- HRU and IBAC ACLs

Jonathan S. Shapiro shap at eros-os.com
Mon Aug 6 15:46:52 EDT 2007


On Mon, 2007-08-06 at 20:03 +0100, David Hopwood wrote:
> In section 3 they say that "In practice,
> typical subjects might be processes", which is definitely not typical for
> current ACL systems.)

Let us not confuse terms further. Subjects in a typical acl system are
definitely processes. What you are getting at here is the issue of
princpals and how they relate to the model. I find that it is clearer to
introduce the equivalence class notion than it is to get the "subject"
and "principal" terms mixed up.

I don't mean to dispute your statement. I just wanted to head off a
potential confusion that would arise from this discussion. If there is a
better framing than equivalence classes, I'm fine with that too.

> # It might also make sense to delete from the matrix any other "reliable"
> # subjects who could grant r, but whom s "trusts" will not do so.
> 
> So, reliable subjects are not assumed to be hostile. But reliable subjects
> are not necessarily in the system TCB. The set of reliable subjects for
> any given right is a function of that right.

But no sensible analysis can assume that ANY non-TCB subject is reliable
given the current state of the art. Things are penetrated too easily for
that assumption to make any practical sense. Making that assumption
reduces the entire exercise to something of the form "if (false) then".
[Regrettably, the same may be said for TCB subjects in most cases.]

What makes the confinement property interesting (at least to me) is that
it lets us evade the need to analyze *every* program without thereby
being naked in public.

> > Specifically, I believe the basic analysis is that any
> > process in the subject graph can and will perform any command that it is
> > capable of performing, subject only to the permission requirements of
> > the commands. In this sense, it is a conservative analysis.
> >
> > This is precisely why trusted subjects must be removed from the graph in
> > order for the analysis to make sense.
> 
> Does considering the set of reliable subjects to be a function of the right
> (which may be either a generic right or a right to a particular object)
> answer this argument? I believe that is the interpretation that the authors
> intended.

I'm fine with that interpretation, and it seems to me that it is
consistent with the intent of the authors. What I am objecting to is the
assertion that untrustworthy subjects can be deemed reliable without any
credible basis in objective reality.

It seems to me that there are two cases where removing a subject from
the model is a sound and sensible thing to do within the intent of the
model:

  1. We are trying to eliminate it from consideration in order to
     determine whether a safety problem may exist elsewhere. That is:
     we are running an experiment of the form "well, assume s1 were 
     not a source of the problem, then what happens?" We might then
     know that fixing s1's program would help us -- or not.

  2. We have analyzed the program code executed by s1, and determined
     based on that examination that s1 may credibly be considered safe.

Perhaps I have missed some other cases under the heading of "what if"
experiments.

Declaring that I consider some subject s reliable merely because I say
so seems more appropriate to a house of worship than to a credible
analysis of security. It's kind of like falling off a very tall
building. When you get to the bottom, gravity isn't going to give a
flying damn whether you believe in the laws of physics. You're still
going to drill a hole in the sidewalk.


So going back to the acl thing: if you are prepared to build a program
as complicated as a shell in trustworthy form, and you can do a credible
analysis on it, then you can remove it from the subject graph.

But as the saying goes: "I'm from Missouri. Show me."


shap



More information about the cap-talk mailing list