Re: [Policy] ACTION-152: Merging NOKIA's input into the policy framework doc

Paddy,

There are benefits to being explicit about trust domains, including  
simplification and clarity in the cases where the trust domain is  
known to be fixed.

You ask whether the trust domain needs to be re-evaluated and I  
suggest it would need to be re-evaluated at application load/launch  
unless known to be permanently fixed. This is the same as evaluating  
policy with implicit trust domains at various points of time. Thus we  
need to be clear of when policy is evaluated in either case.

I suggest we decide next week to agree to using explicit trust domains  
and then work though the details - it sounded on this week's call that  
this was generally acceptable.

Thanks

regards, Frederick

Frederick Hirsch
Nokia



On May 5, 2010, at 9:59 AM, ext Paddy Byers wrote:

> Hi,
>
> I'd like to introduce a proposal to merge NOKIA's submission into  
> Policy
> Framework doc. Below I try to point out how would this changes impact
> the current document. It would be good to discuss it in today's call  
> and
> see what editorial changes are required and if these changes are going
> to bring major improvements to the security framework.
>
> I'm sorry but I won't be able to join the call today because of a  
> conflict.
>
> I think there's quite a bit of investigation needed to understand  
> how your suggestion would work. I agree with the idea that it would  
> be useful to be able to localise the definition of the two separate  
> concerns of trust and access (ie which subjects are grouped  
> together, based on their identifying attributes, and what access is  
> permitted for each group). However, I think that in doing that there  
> is a likelihood that the functionality will change quite  
> significantly (ie the policies that can be expressed will be  
> different).
>
> A couple of issues that come to mind immediately:
>
> - exclusivity of trust domains: is it the case that once the trust  
> domain for an application is determined, it belongs to that domain  
> and no others? With a BONDI policy, this isn't the case: a subject  
> can matche the target for a given child policy (ie belong to the  
> "trust domain" associated with that policy) but if none of the rules  
> of that policy apply, then the higher-level combining rules will  
> then cause other sibling policies to be relevant. So it is possible  
> to define "trust domains" that apply with a specific scope, and  
> which overlap with other trust domains.
>
> - subject attributes in rule conditions: in a BONDI policy, subject  
> attributes can be used to determine which rules apply at a rule-by- 
> rule level, instead of only at the level of the target on a policy.  
> It isn't clear whether or not the same policies can be described if  
> the two aspects are made completely separate.
>
> So before thinking about changes to the document itself, I think we  
> need to think through what it would mean in terms of the logical  
> model, and how well the resulting model addresses the various use  
> cases. The one I keep coming back to is the ability for user  
> decisions to be recorded themselves in the policy language (eg  
> permit this operation for this application, or permit this operation  
> for all applications from the same author, or deny this operation  
> irrespective of the trustworthiness of the application).
>
> Thanks - Paddy
>

Received on Thursday, 6 May 2010 17:39:58 UTC