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

Toby Murray toby.murray at comlab.ox.ac.uk
Mon Aug 6 10:50:09 EDT 2007


On Mon, 2007-08-06 at 10:35 -0400, Jonathan S. Shapiro wrote:
> On Mon, 2007-08-06 at 14:50 +0100, Toby Murray wrote:
> > On Fri, 2007-07-27 at 17:03 +0100, Toby Murray wrote:
> > > On Fri, 2007-07-27 at 11:50 -0400, Jonathan S. Shapiro wrote:
> > > > On Fri, 2007-07-27 at 11:55 +0100, Toby Murray wrote:
> > > > > The question I was
> > > > > asking was whether the formal access control model (identity-based ACLs
> > > > > with so-called "discretionary" access control and the superuser) can
> > > > > enforce the safety property. Of course they can -- that was my point.
> > > > 
> > > > The answer is NO. Go re-read the HRU paper.
> > > 
> > > I will. But I don't remember anything in that paper to support your
> > > claim from last time I read it. I'm hoping that if re-reading the paper
> > > doesn't convince me you're right, that you could point to the relevant
> > > section in which this claim is proved.
> > 
> > I've now re-read that paper. 
> > 
> > (see a PDF here
> > http://www.cs.unibo.it/~babaoglu/courses/security/resources/documents/harrison-ruzzo-ullman.pdf )
> > 
> > Having done so, I see no evidence to support the claim that the safety
> > property cannot be enforced using identity-based ACLs with so-called
> > "discretionary" access control (i.e where the "owner" of an object can
> > control which subjects have permission to access it).
> 
> 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. 

> 
> > So say we have a system of 2 subjects, s1 and s1, and one (file) object
> > f.
> > 
> > Say that s1 is the owner of f (i.e. "own" is in (s1, f) )
> > And we want to determine whether s2 (who is considered untrustworthy)
> > can obtain the right to "read" f. s1 is considered trustworthy, so we
> > remove it from the configuration, leaving a configuration with 2
> > entities (s2 and f) in which no entity has any permission to any other.
> 
> 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.

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

>  This is
> comparable to saying that every program that a user U might run on the
> system is known to be completely safe.

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.






More information about the cap-talk mailing list