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

[Toby Murray]

On Mon, 2007-08-06 at 15:46 -0400, Jonathan S. Shapiro wrote:
> > 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.

That seems pretty harsh coming from the author of the Boebert refutation
which itself uses a non-TCB trusted subject to enforce the *-property.
I'm afraid it's looking too contradictory to me.

Don't get me wrong. I love caps; but I can't help feeling that this
looks like an uneven playing field tilted in their favour.


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

Sorry. I must have been unclear. It was never my intention to put this
point of view across. When I'm talking about trusted subjects, I'm
thinking of the same sorts of trusted subjects used in cap systems to
build security-enforcing abstractions -- since in both cases they
perform the same function: behave in such a way to enforce some security
invariant (e.g. a permission does not propagate.)


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

I agree that if there are other cases when we should do this, I haven't
thought of them. I wouldn't advocate removing s1 in other circumstances
and haven't tried to do so (although I may not have been sufficiently
clear to get that point across.)

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

Absolutely. But sometimes we are left with no choice. Regardless of
reality, if I want to get work done, I need to trust bash. Hence, when
performing a safety analysis of UNIX, I would probably treat bash as a
trusted subject. That may be an unwise choice in all circumstances, but
I believe there might exist circumstances in which this is a reasonable
thing to do. For example, I might be trying to determine whether another
use can obtain read access to a sensitive file. By assumption, I'll
presume that bash won't leak the permission; otherwise I can't get any
useful answers. Hence, I don't see that my position is as untenable as
you (but of course if I did, we wouldn't disagree ;)


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

This is the safest way in which to decide to remove the shell from the
subject graph. 

Consider Plash. When one uses and thinks about Plash and the security
properties it affords, we presume Plash is trustworthy in order to
perform the analysis. (Here of course I'm referring to informal thought
experiments, but the principle remains the same.) 

Cheers

Toby