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

[David Hopwood]

Jonathan S. Shapiro wrote:
> On Mon, 2007-08-06 at 14:50 +0100, Toby Murray wrote:
>> 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.
> 
>> 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.

ACL systems don't distinguish between subjects and principals, so all
programs running on behalf of a given principal are the same subject.
You're quite correct that this means we cannot reasonably treat that
subject as trustworthy.

> Because of this, we cannot reasonably introduce the assumption that s1
> is non-hostile.

"Hostile" would imply deliberate intent to act against the principal's
interests. Indeed there may be hostile programs involved (viruses,
executable attachments, etc.), but even if there were not, it would be
sufficient that we can't treat all programs running as s1 to be
*trustworthy* -- because it is impractical to exhaustively review the
source of all such programs.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>