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

Jonathan S. Shapiro shap at eros-os.com
Mon Aug 6 16:44:18 EDT 2007


On Mon, 2007-08-06 at 21:30 +0100, Toby Murray wrote:
> 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.

Which one is that? Both the constructor/factory logic and the KeySafe
logic would *certainly* be considered part of the TCB.

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

Excellent. But in an ACL system, I don't see how trusted subjects can
enforce boundaries, because ACL systems do not restrict authority
propagation. The problem is that (1) create has no preconditions and
yields "own" (2) the grant right has "own" as a precondition, but not
"write(intended-recipient)". So you either need to take out grant or
create or you need to fundamentally redefine own.

Both of those are fine things to consider doing. The problem is that
once you have done them, you no longer have a system that can reasonably
be called an ACL system.

SELinux is one example: it overlays onto the ACL system an intersecting
constraint set. The result is neither ACL, TE, nor RBAC, but some hybrid
of these. In such a system I agree that interesting constraints are
possible.

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

Good. So which definitive property of ACL systems are you proposing to
remove?


shap



More information about the cap-talk mailing list