User: Password:
|
|
Subscribe / Log in / New account

Arbitrary 3rd Party Code

From:  "Ryan Ware" <ware-VuQAYsv1563Yd54FQh9/CA-AT-public.gmane.org>
To:  <meego-security-discussion-VVXm0OgCXj10cC2WI2GV6A-AT-public.gmane.org>
Subject:  Arbitrary 3rd Party Code
Date:  Wed, 6 Apr 2011 12:27:09 -0700
Message-ID:  <01ba01cbf490$9fa108f0$dee31ad0$@linux.intel.com>
Archive-link:  Article

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


(Log in to post comments)


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds