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

On 21/02/13 13: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.
>
> [...]
>
> 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.
> 
> [...]
> 
> 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.

I think (c) and (d) should be defined by the API given that you define
the required level of access depending on how easy it is to attack the
user, how bad the attack can be for the user and how interesting the
attack is for the attacker.
Basically, an attack that is easy to do, doesn't hard much the user and
doesn't give much to the attacker isn't really worth worrying for.

For example, it is pretty easy for an attacker to bother the user by
rotating the screen or sending notifications all the time but there is
no point for the attacker to do that and the user will easily get ride
of the application. It is exactly the same in browsers: you can easily
open dozens of popups on a single click event but most of the time,
websites doing that will open only one popup. But on the other hand, as
soon as a way to open pop-under is found, it is heavily used.

The other side of that is things like sending an SMS. Even if we make it
very hard to send an SMS without user consent, the harm to the user is
so high (less money) and the benefit for the attacker is so high
(sending SMS to premium number) that we will have a hard time to allow
SMS to be sent by any application. The Android Marketplace is full of
malware like that. Someone in French has recently being arrested; he was
able to get 500'000€ with such a malware.

Anyway, I think the best thing the runtime specification can say is
something amongst those lines. It is harder to make any more assumption
whether for (c) or (d).

Cheers,
--
Mounir

Received on Monday, 25 February 2013 17:34:14 UTC