Re: [Execution and Security Model] Proposal from Samsung Electronics

On 2013-02-21 14:10, John Lyle wrote:
> On 21/02/13 11:00, Janusz Majnert wrote:
>> Another issue I wanted to bring up here is the number of "trust
>> levels" in the specification. Do you think 2 is enough?
>> With 2 levels, we would have to put all security and privacy sensitive
>> APIs in the second (trusted) level. It's an all-or-nothing situation.
>> Wouldn't it be better to separate this level into two and allow
>> implementations to configure how the APIs are distributed among them?
>
> Hi Janusz,
>
> Apologies if this is all obvious to everyone else, but for my
> understanding can we just separate out a few things?  When it comes to
> talking about 'trust levels' there are the following concerns:
>
> (a) The knowledge of the integrity and authenticity of the application
> and its content ('trustability' to some)
> (b) The belief that the user (or another authority) may have in the
> application's good behaviour ('trustworthiness' to some).
> (c) The threat of a malicious application misusing a particular API.
> (d) The rules governing which types of applications can access which APIs.
This is a really good summary of the span the word "trust" covers in 
SysApps context. When writing my previous email, I completely forgot 
about this and instead used the term as it was used in the context of 
WAC, which maps to your point (d).

> It's worth having levels to classify applications on the grounds of
> (a).  E.g., is the application the one that we think it is?  If it's
> served over HTTP, or in an unsigned package that has never been used
> before, we don't know, so 'untrustable' ought to exist as a level.
>
> If it *is* trustable, then you can begin to categorise it based on (b).
> E.g., does the user have good experiences with the application (or the
> developer) and do they therefore believe it to be a non-malicious
> application?  As well as the user's opinion, the same question can be
> asked of other authorities (anti-virus companies, app stores or
> manufacturers).  These can be expressed as distributor signatures or in
> other ways.  You can therefore imagine a range of levels here, depending
> on how many parties are involved.  Each system might define its own set
> of levels depending on the combination of certain opinions by different
> authorities. WAC has four levels based on concerns (a) and (b) [1].  You
> could also treat every application completely independently.
>
> As an orthogonal issue, there's (c) - the analysis of APIs based on the
> impact of them being misused.  Each API might be considered
> independently, or one might lump applicationsinto two categories -
> 'safe' and 'unsafe' or three - 'safe', 'unsafe' and 'dangerous', or any
> other system.  Onemight also define pre-requisite UI flows and
> constraints required to use each API, as I believe Mozilla did with
> their API analysis [2].
>
> Finally, there's (d) - the rules dictating whether a certain API or API
> category should be made accessible to a certain application category. Do
> 'untrustable' applications have any access to the 'unsafe' APIs? And so
> on.  There's overlap with step (c) of course.
>
> You are suggesting that there should be 3 levels to deal with (a) and
> (b), each API should be treated independently for (c) and that (d)
> should be down to the platform implementation.  Right?
No. I took the shortcut and proposed 3 levels of access to API (d).

> In Mounir's proposal, there are 'trusted' and 'untrusted' applications,
> so 2 levels for part (a) and (b).  There's no definition for (c) or (d),
> so presumably these are platform-dependent.
>
> I would like to see at least three levels for (a) and (b) to capture
> applications that are 'untrustable', 'trustable but not considered
> trustworthy' and 'considered trustworthy'.  Then I'd like to see some
> analysis of APIs to define (c) on a per-API basis.  For (d) I'd like to
> see the specification contain recommendations.
Based on my experience with WAC, the definitions of levels you're 
proposing for (a) and (b) may significantly vary from country to 
country, especially if we consider east Asia. The analysis for (c) would 
also have to take into account cultural differences in the understanding 
of privacy.
In fact, I think that (d) is the only area we can address in the 
specification, leaving all the rest to implementations and deployers 
(operators, system vendors etc).


Best regards,
Janusz Majnert

Received on Thursday, 21 February 2013 14:24:10 UTC