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

[casey.schaufler at nokia.com]

> -----Original Message-----
> From: ext Praveen Gupta [mailto:pgupta at mobilestack.com]
> Sent: Thursday, April 07, 2011 2:12 PM
> To: Schaufler Casey (Nokia-SD/SiliconValley)
> Cc: meego-security-discussion at lists.meego.com
> Subject: RE: [Meego-security-discussion] Arbitrary 3rd Party Code
> 
> 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"..

I would go further than saying that I question the requirement.
What I appear to have to done is fail in my attempt to point
out that the requirement as stated is nonsensical. It does not
describe a behavior that is verifiable. There is no way that a
test could be written or documented that would identify whether
or not a system met the stated "requirement". 


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

I am not assuming that there is no solution, I am challenging
your problem statement.


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

Sigh. Reread your "requirement". Define "stolen" and "unintended"
such that they are testable.


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

Stop saying that! Gee Wiz, do you think that if you say
the same thing enough times it will become true?


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

Errrrrrrrr ....

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

Why not? It isn't stealing the data, nor is it using it
for an unintended purpose.


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

Actually, I proposed an implementation. You don't like it and
are convinced that "enterprises" won't like it either. The
rhetorical question is used in this context to emphasize the
undesirability of the solution.


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

No, I am taking your stated requirement apart at the joints and
tossing the pieces to the stray dogs. Read my arguments.

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

I have an Orange Book B1 certificate on my wall.

The reason that an evaluation took 5 years and a million dollars
is that by the time you included everything you needed to have a
useful system within the TCB you had too much stuff.


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

You are correct. In itself it does not solve a problem any more than
getting fuel loaded onto the plane gets you across the Atlantic. It's
something you can chose to ignore if you want to make things hard.


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

Of course it makes sense to consider requirements. It is of
critical importance that requirements be valuable, objective
and verifiable.

The problems with the proposed requirement statement are:
    - It is defined in the emotionally laden terms
      "stolen" and "unintended".
    - It defines value solely in those terms.
    - The definition is completely subjective.
    - Only a court of law can determine if something was stolen.
    - How on earth are you going to test what was intended by the
      user of an arbitrary 3rd party application?

Oh, I could implement something that claims to meet your
requirement statement. I doubt that it would add any real
value because the statement is completely subjective and even
if it fit your vision it wouldn't work for the person seated
to your left.