Re: Arbitrary 3rd Party Code

> -----Original Message-----
> From: casey.schaufler-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org
[mailto:casey.schaufler-xNZwKgViW5gAvxtiuMwx3w@public.gman...
> Sent: Wednesday, April 06, 2011 1:43 PM
> To: ware-VuQAYsv1563Yd54FQh9/CA@public.gmane.org;
meego-security-discussion-VVXm0OgCXj10cC2WI2GV6A@public.gmane.org
> Subject: RE: [Meego-security-discussion] Arbitrary 3rd Party Code
> 
> 
> ________________________________________
> > From: meego-security-discussion-bounces-VVXm0OgCXj10cC2WI2GV6A@public.gmane.org
> > [meego-security-discussion-bounces-VVXm0OgCXj10cC2WI2GV6A@public.gmane.org] on behalf of ext
> > Ryan Ware [ware-VuQAYsv1563Yd54FQh9/CA@public.gmane.org]
> > Sent: Wednesday, April 06, 2011 12:27 PM
> > To: meego-security-discussion-VVXm0OgCXj10cC2WI2GV6A@public.gmane.org
> > 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.
> 
> There are other ways to use Smack, too. The previously described plan
> included integration with the Nokia backed "creds" abstraction. This is a
> more complex approach than using Smack directly.

Very true.  By "similar fashion" I do mean Smack without "creds".  We no
longer need that abstraction.  

> > ** We may move to SELinux.
> 
> Great Godfrey Daniels!

:-)

> > If so:
> > *** The generic policy will be generally lightweight and fairly
> permissive.
> 
> Not if it has any relationship to the Reference Policy it won't be.
> If you try to use any policy that is not based on the reference policy you
> will discover that to most minds the Reference Policy defines the expected
> behavior of an SELinux based system.

At this point I want nothing to do with the Reference Policy.  I would much
prefer to focus on a limited set of functionality around privacy controls.
I know that means it won't necessarily exhibit "expected" SELinux behavior.
Given the relatively limited range of verticals we are trying to support, I
believe we will be able to get away with that.

> > **** This can be tweaked by the integrator to reflect their own
> > security requirements.
> 
> There are very few integrators, even in the military and intelligence
> arenas, who feel sufficiently confident with their SELinux policy skills
> to do any tweaking that isn't directly targeted at disabling the SELinux
> controls.

This is all-to-true and will be a barrier if we go down this path.  At the
same time, I do regularly get asked if we will support SELinux by potential
customers.  I don't know if they always understand what they are asking for
but they do ask.

> > *** The generic policy is strict around items with security sensitivity.
> > *** SELinux would enforce permissions on dbus.
> 
> Yeah.
> 
> > * 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.
> 
> If you're going top throw SELinux into the mix you are not going to make
> anything simpler. It would be easier to create an LSM that does exactly
> what you want than to create a rational SELinux policy.

If we were going to use the SELinux reference policy, I would completely
agree.  However, looking at something that would focus more on the SELinux
privacy controls would limit the complexity.  You're correct that it might
be easier to create an LSM that does exactly what we want.  Because of MeeGo
policies though, that would mean I would have to get it upstreamed first
before we could use it and that would be problematic.  ;-)

> 
> Of course, as the author of Smack, I have my biases.

Yes you do Casey, but I strongly appreciate your arguments regardless of
those biases.  :-)

Ryan