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

Jonathan S. Shapiro shap at eros-os.com
Mon Aug 6 12:50:54 EDT 2007


On Mon, 2007-08-06 at 15:50 +0100, Toby Murray wrote:
> On Mon, 2007-08-06 at 10:35 -0400, Jonathan S. Shapiro wrote: 
> > Very simple: the owner does not control. The programs labeled with the
> > owner's principal ID control. The model assumes that all programs are
> > maximally hostile. Therefore, in any system where at least one subject
> > executing on behalf of the owner exists, the access right leaks in a
> > single step.
> 
> Your argument appears (to me) to be suffering the exact same problem
> that the Boebert et. al. argument did regarding the inability of a cap
> system to enforce the *-property. Trusted subjects need to be taken into
> account in both cases. Failing to do so leads to overly pessimistic
> results. 

I disagree. I am not failing to take into account trusted subjects. The
problem is on the other foot: you are failing to admit any untrusted
subjects.

An unstated assumption in the HRU model is that the access right of
interest is initially held by some non-trusted subject.

> > This is not an accurate model. The problem with this model is that
> > subjects in an ACL system do not own objects; principals do. Therefore,
> > the set of subjects that effectively possess the "own" right is an
> > equivalence class induced by principal id. 
> 
> No worries. So we have the model maintain a set of subjects for each
> principal. All subjects corresponding to principal p have identical
> permissions. Say s1 corresponds to principal p1 and s2 corresponds to
> principal p2. If s1 is trusted by p1, there's no reason not to exclude
> it from the model as HRU advocate. Doing anything less prevents the use
> of trusted subjects to enforce security properties.

But you are left with a model that is safe only in the trivial and
highly specialized case. This is not the case that the model seeks to
address.

> > Because of this, we cannot
> > reasonably introduce the assumption that s1 is non-hostile.
> 
> Unless s1 actually is non-hostile. s1 might be my shell, which I presume
> to be non hostile. This appears to be Boebert's mistake reflected by one
> of his loudest critics. I don't get it...

Your shell is not part of the TCB. It is assumed to be hostile.

Back up. This is a model in which all processes that are not part of the
TCB are assumed to be perfectly hostile. What you are doing is removing
all subjects of interest from the graph by declaring them trusted. At
that point, your process s1 will no longer exist in the graph at all,
and it will not be possible to express within the model the fact that s1
holds rights at all.

> I disagree. Its comparable to saying that some programs that a user U
> might run are known to be safe and hence, these subjects (that represent
> these programs) should be removed from the model.

Yes. But once you remove them from the model they don't get to hold
access rights.

shap



More information about the cap-talk mailing list