[Meego-security-discussion] Arbitrary 3rd Party Code

[Rene Mayrhofer]

On 07.04.2011 22:01, casey.schaufler at nokia.com wrote:
> It is impossible for your computer to tell if the application is using 
> the data you have granted it access to in the way you intended it to.
For most of the _practical_ use cases, I think that it is possible to 
detect this.

Imagine for example a game application that should be able to set 
reminders for <doing something or other that is part of the game> in the 
user calendar. As another (unrelated) function of the game, it needs to 
communicate with a central server to exchange <high scores etc.>. Upon 
installation time, the user might grant the application access to the 
calendar to post and maybe read and modify/delete existing entries as 
well as allowing it to connect to this server.

However, that does not mean that the application should be allowed to 
send calendar data to the server. If data from different sources (such 
as the calendar) was tagged appropriately and was not allowed to be sent 
over network connections, we could solve a significant amount of privacy 
leaks.
Is this possible with any current system that I know of? No. May we want 
to protect against it? Yes. Will it be possible to protect against rogue 
applications that read private data in one context and then apply 
encryption/steganography/whatever to get them into another context 
without this being detected? No.
The question is therefore more a compromise: given limited resources and 
a finite-length security policy, against how many "standard" threats can 
we protect? By solving 90% of those cases where Android applications 
currently violate the "intended"/"expected" behavior, we would already 
have made a large improvement.

In principle, I am in favor of security models as simple as possible. 
The Android model works because it is simple to understand for 
application developers and offers reasonable security. It is far from 
perfect (e.g. the all-or-nothing approach to capabilities when 
installing applications, or the complete lack of kernel- and user-level 
protection against well-known attack vectors (think NX/XN, ASLR, etc.), 
but IMHO the concept is something to keep in mind as a basis for 
improvement.

best regards,
Rene