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

[Praveen Gupta]

See my response with "praveen>"

Thx,

> -----Original Message-----
> From: casey.schaufler at nokia.com [mailto:casey.schaufler at nokia.com] 
> Sent: Thursday, April 07, 2011 1:01 PM
> To: pgupta at mobilestack.com; ware at linux.intel.com;
meego-security-discussion at lists.meego.com
> Subject: RE: [Meego-security-discussion] Arbitrary 3rd Party Code

> > -----Original Message-----
> > From: meego-security-discussion-bounces at lists.meego.com [mailto:meego- 
> > security-discussion-bounces at lists.meego.com] On Behalf Of ext Praveen 
> > Gupta
> > Sent: Thursday, April 07, 2011 12:01 PM
> > To: 'Ryan Ware'; meego-security-discussion at lists.meego.com
> > Subject: Re: [Meego-security-discussion] Arbitrary 3rd Party Code
> > 
> > Fundamentally, I agree with new "requirement statement" which Arjan 
> > has proposed i.e. to focus on "user data security" for Meego Security 
> > Architecture. In my assessment, Meego (and Android) fail to support 
> > fundamental user-data security requirements.
> > 
> > The key problem:
> > * How to make sure that newly installed application is not "stealing"
> > user-data and sending it to servers for un-intended purpose.

> You can't.

> It's a 3rd party application. You have granted it access to some set of
your data. You want that application to talk off-box. All of the data that
you have granted it access to may show up on www.tonsofun.com and there is
nothing that your computer can do to stop it.

Praveen> Do you question the requirement ? or You do NOT have solution for
it ? Once, we agree on the requirement then solutions will "evolve". I can
propose a solution.. However, We need to *first agree* on "requirements".. 


> 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.

Praveen> Again... You are assuming that there is NO solution / architecture
to support such a requirement.. I dis-agree with this.

> The computer cannot tell the difference between communicating what you
want the application to say to a server and information that you don't want
it to.

Praveen> Again... You are assuming that there is NO solution / architecture
to support such a requirement.. I dis-agree with this.

> The computer cannot tell the difference between you doing an online backup
of your finance data, you filing a tax return, or the application sending
unauthorized sell orders to your broker.

> Further, the computer cannot determine if the application is malicious,
flawed, being used incorrectly or if it is doing everything as directed by a
really stupid user.

Praveen> Again... You are assuming that there is NO solution / architecture
to support such a requirement.. I dis-agree with this.

> Not to mention that the application could very well be coming to its own
conclusions about your finances based on how you use the program. That
information is every bit as sensitive as what you have on your disk. How on
earth can you expect the computer to determine that this information might
not be something you want sent?

Praveen> Again... You are assuming that there is NO solution / architecture
to support such a requirement.. I dis-agree with this.

> > Google is known to send (silently) "user-location" data and then use 
> > it for advertising WITHOUT user's consent.

> Deep breath ...

> Most people in the world see this as a feature.

Praveen> It is a feature if user "wants" it...  Do not "assume" that
every-body "wants" this feature. 


> Any bit of information that your mobile device emits is potentially
consequential. Do you want to examine every packet?

Praveen> You cannot convince "enterprises" to believe in "such a
framework"... Again, you feel that requirement is *not implementable" .. I
will not jump to such a conclusion.... 

> Windows anti-virus programs use dialogs to request consent to make
connections. Do you really want that? 

> > Meego security architecture fails to support this purpose as well.
> > 
> > SELinux was NOT created to support this requirement. Hence, it is no 
> > surprise that SELinux does not support this functionality.
> > 
> > The requirement is to ensure that software (mobile application in
> > particular) is *not* sending "stolen" data over-network to servers. We 
> > need "creative" access-control mechanism to enforce this requirement.

> You also need intelligent, careful and deliberate users who are capable of
unraveling compressed and encrypted > data streams from hex in real time.

> You need a definition of "stolen" that allows the same application on the
same computer to send the same set of information to the same destination
twice where one transmission constitutes legitimate use and the other theft.

> > Again, I am not proposing a solution here. We need to *first agree* on 
> > the security problem statement.

> The only way you can possibly solve the "security problem" stated above is
to include all the code that runs on your computer within the security
perimeter.

> That means that the behavior of all the applications is known and
acceptable to an explicitly stated set of rules regarding the sharing of
information.

> You also have to include all of the remote services with which your
computer communicates in the security perimeter lest they communicate among
themselves in ways that provide for aggregation of user data in violation of
those rules.

Praveen> Again, it seems that you are *refusing* to even consider that
"requirement is valid" as you do not have a solution / architecture for it. 

> The good news is that with an Orange Book (possibly with a Red Book
component) system from the 1980's you can have just what you are asking for.
The bad news is that the Orange Book died for a reason.
> That reason being that no one wants that level of control.

Praveen> Orange book died because of end-less testing loops for products to
certify.. This created un-acceptable cost structure to support organge-book
certified products.

> Ryan's conclusion that there need to be trusted and untrusted sides does
not come lightly, and is backed by decades of experience with security in
defense, banking, finance and commerce.

Praveen> Separation of trusted / un-trusted is a "step" in the right
direction.. However, it is not a complete solution. Once we "accept" that
requirement is valid then architecture proposals can be solicited.. 

Praveen> Different companies / contributors can then  propose a solution if
we all agree that requirement is valid.. 

> 
> Thanks,
> 
> -----Original Message-----
> From: meego-security-discussion-bounces at lists.meego.com
> [mailto:meego-security-discussion-bounces at lists.meego.com] On Behalf 
> Of Ryan Ware
> Sent: Wednesday, April 06, 2011 12:27 PM
> To: meego-security-discussion at lists.meego.com
> Subject: [Meego-security-discussion] Arbitrary 3rd Party Code
> 
> Since Arjan announced changes in the security direction for MeeGo, 
> I've had a large number of questions regarding what the new 
> architecture is going to look like.  I want to emphasize that this 
> direction isn't set in stone.
> I
> would like feedback from people in the community to determine if this 
> fits their needs and if not, it what ways does it fall short.  This 
> will be significantly different from MSSF, but I believe it fits our 
> current security requirements and is simpler to implement.  Keep in 
> mind that this is an overview.  I will be generating a detailed 
> architecture over the next couple of weeks.  There are also some areas 
> that I will not yet touch on because they haven't been grounded yet.
> 
> To start, I'm intending to break things up conceptually into a Trusted 
> Side and Untrusted Side.
> 
> Trusted Side:
> 
> * The Trusted Side in many ways is like MeeGo today
> * It *does* include secure software distribution as was originally 
> planned for MSSF including trust levels.
> * It includes (with a few exceptions discussed later) the 
> core+vertical stack that is delivered by MeeGo with the possibility of 
> other additions by the platform integrator.
> * It *does* use a Linux Security Module (LSM).  Which LSM has not been 
> decided.
> ** We may continue to use SMACK in a similar fashion to what was 
> previously described.
> ** We may move to SELinux.  If so:
> *** The generic policy will be generally lightweight and fairly 
> permissive.
> **** This can be tweaked by the integrator to reflect their own 
> security requirements.
> *** The generic policy is strict around items with security 
> sensitivity.
> *** SELinux would enforce permissions on dbus.
> * It runs out of the "default" btrfs root.
> 
> Untrusted Side:
> 
> * This side is for:
> ** MeeGo packages that historically have security concerns such as web 
> browsers.
> *** This list can and would change over time as developments warrant.
> ** Arbitrary 3rd party code such as untrusted appstore apps.
> * These applications would run in:
> ** A Linux Container
> ** An application-specific btrfs snapshot for the filesystem
> *** The snapshot can be generated by a tool using the rpm dependency 
> tree.
> * Every application would have their own app-specific storage and 
> would be given permissions to access to end-user data depending on 
> what software repository the application came from and the trust level 
> associated with it as well as permission granted by the end-user at 
> installation time.
> 
> Benefits:
> 
> * Changes for existing code running in Trusted Side are minimal beyond 
> the changes for data protection that are being discussed in other 
> threads.
> * Malicious 3rd party software or chronically vulnerable software 
> cannot affect software running outside of their container and 
> shapshot.
> ** An application shapshot could be regenerated if unwanted changes 
> were detected.
> * The immediate access control story becomes much simpler.  We have a
> *relatively* static and well defined set of functionality provided in 
> the Trusted Side allowing us to create appropriate security policies 
> for each of the verticals.
> * The immediate integrity protection story becomes much simpler.  We 
> will rely on access controls to enforce protections.  However, in the 
> long- term we want to still explore supporting IMA/EVM for people who 
> have security requirements demanding those strict types of controls.
> 
> As I said before, I understand that this is different from what has 
> been previously discussed.  I would like to gauge feedback for this 
> simplified direction and see if it meets people's needs.
> 
> Ryan
> 
> _______________________________________________
> MeeGo-security-discussion mailing list 
> MeeGo-security-discussion at lists.meego.com
> http://lists.meego.com/listinfo/meego-security-discussion
> 
> 
> 
> _______________________________________________
> MeeGo-security-discussion mailing list 
> MeeGo-security-discussion at lists.meego.com
> http://lists.meego.com/listinfo/meego-security-discussion