[Meego-security-discussion] [MeeGo-community] How Android solves credential stealing issue // why not same security for MeeGo?

[Niels Mayer]

On Wed, Jan 12, 2011 at 10:43 PM, Brian McGillion
<brian.mcgillion at symbio.com> wrote:
> The following is a demo from a Qt app view:
> http://meego.gitorious.org/meego-platform-security/mssf-demo

Brian --

Thanks for the pointer, which reminded me to listen to your talk again
at http://conference2010.meego.com/session/cost-security-developers-view .
Do you have the matching slides for this talk? It's a little hard to
follow w/o the slides; now that I've found "Tools->Git->Branches..."
in qt-creator, it's a lot easier to understand what's going on based
on the GIT repository you referenced. I also took the opportunity to
re-watch
http://conference2010.meego.com/session/mobile-simplified-security-framework-overview
( http://conference2010.meego.com/sites/all/files/sessions/meego-conference-overview_v_final.pdf
) and I'm getting a clearer picture of things.

The latter now suggests to me that MeeGo has at least the same default
level of security as Android, but solves it more elegantly and more
extensibly w/ potential to utilize hardware-based access keys. The
biggest security feature is the mainline Linux  kernel support of
SMACK and therefore MeeGo's solution is more "open" and secure.
Android sandboxes apps by creating separate pseudo-users using
traditional unix access control to separate apps as "users", whereas
MeeGo uses filesystem extended attributes containing SMACK labels, and
doesn't "hack" the semantics of a Unix user like in Android. In MeeGo,
apps are, by default, installed with a unique new label, and SMACK
extends the kernel access control to include matching these labels in
addition to traditional user/group/other. Therefore, in MeeGo 1.2,
applications accessing resources with a given unique label are
equivalent, in "sandboxyness," to Unix's separation of users that
Android exploits with its pseudo-users.

The MeeGo application's unique label permits only itself to read/write
areas in the filesystem containing its label, or areas where it has
been given explicit write access; likewise the label would prevent
writing to- or reading from- other process' data unless explicit
install-time rules are set up specifying details of inter-process and
filesystem access. The label system extends down to the packet level
in the network interfaces, allowing access control of information
taken from. or written to, the network interfaces.

The one big question, having never used a security system like the
above, is the performance impact, especially if packet-level access
control is being used.  I look forward to being able to use a system
with such exciting and leading-edge security features;  the appearance
of commercial phones by the end of this year promising such security
will be a big technical step forward.

One further question I have is whether "open mode" versus "closed
mode" is too severe a distinction. Seems like the MeeGo security
architecture could permit a "mixed" mode interface given
hardware-based access control to the "sensitive" components: e.g., the
cellular radio interface to keep it within local regional compliance;
for playback of DRM material without being able to copy the decrypted
bits within the system; and for protected materials such as map data,
certificates and access tokens.

> I believe that many developers are conscientious enough to want to store
> their resources and settings securely, but may be concerned about the
> complexity that encrypted/signed storage will bring.  So simple, easy to
> use tools are all the motivation they will require and Mssf-crypto
> provides this.

Developers are conscientious, but "lazy" or rather overwhelmed with
way too much scaffolding and seemingly irrelevant details between what
they want to accomplish and how they end up having to accomplish it.
So anything that makes this process more transparent is good, such as
your work on the mssf-demo apps.

However, it's nice to know the underlying OS is being used to
"backstop" other more traditional ways to separate applications from
each other. Since the apps I'd worry about are the underlying legacy
library that some app uses -- like the ones leaving an open unix
domain socket open in /tmp that can expose a shell, or the scenario of
storing credentials or bookmarks in legacy configuration files.

-- Niels
http://nielsmayer.com

PS: incase others are interested, here's some links related to this
subject that I've gathered, for further reading:

Linux kernel:
 http://linuxplumbersconf.org/2009/slides/Casey-SmackPlumbers2010.pdf

Meego:
 https://www.nixuopen.org/blog/2010/11/developing-for-meego-part-2/
 http://lwn.net/Articles/414816/ (A high-level view of the MeeGo
security landscape)
 http://conference2010.meego.com/session/meego-security-what-it-and-why-do-we-care
 http://lwn.net/Articles/373780/ (FOSDEM'10: Maemo 6 platform security)
 http://wiki.meego.com/images/MSSF_Slides_OLS2010.pdf
 http://wiki.meego.com/images/MSSF_OLS2010.pdf
 http://conference2010.meego.com/session/mobile-simplified-security-framework-overview
 http://conference2010.meego.com/sites/all/files/sessions/meego-conference-overview_v_final.pdf
 http://www.slideshare.net/reshetov/mobile-simplified-security-framework
 http://meego.gitorious.org/meego-platform-security/pages/Home
 http://meego.gitorious.org/meego-platform-security/pages/Overview
 http://meego.gitorious.org/meego-platform-security/pages/Functionality
 http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf
 http://wiki.meego.com/Quality/Plans/MeeGo_Security_Test_Plan

Maemo:
 http://wiki.maemo.org/MaemoSecurity
 --> http://www.slideshare.net/peterschneider/maemo-6-platform-security
 --> http://meego.gitorious.org/meego-platform-security
 --> http://wiki.maemo.org/Talk:Maemo_security
 http://archive.fosdem.org/2010/schedule/events/maemo
 http://wiki.maemo.org/Maemo_security#What_is_.22Open_Mode.22_and_can_it_be_revoked_remotely.3F

ARM:
 http://www.arm.com/products/processors/technologies/trustzone.php

Android:
 http://www.scribd.com/doc/43524001/Android-Web-Service
 http://developer.android.com/guide/topics/security/security.html