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

[Ryan Ware]

> -----Original Message-----
> From: casey.schaufler at nokia.com [mailto:casey.schaufler at nokia.com]
> Sent: Thursday, April 07, 2011 8:24 AM
> To: elena.reshetova at nokia.com; nielsmayer at gmail.com; ware at linux.intel.com
> Cc: meego-security-discussion at lists.meego.com
> Subject: RE: [Meego-security-discussion] Arbitrary 3rd Party Code
> 
> 
> ________________________________________
> From: Reshetova Elena (Nokia-SD/Helsinki)
> Sent: Thursday, April 07, 2011 12:23 AM
> To: ext Niels Mayer; Schaufler Casey (Nokia-SD/SiliconValley);
> ware at linux.intel.com
> Cc: meego-security-discussion at lists.meego.com
> Subject: RE: [Meego-security-discussion] Arbitrary 3rd Party Code
> 
> 
> > Hi,
> 
> 
> > > Any comments on the findings in the aforementioned paper "SELinux
> > >for Consumer Electronics Devices"
> > >(Yuichi Nakamura and Yoshiki Sameshima, Hitachi Software Engineering) ?
> 
> > I remember reading the paper when it was published and there were
> > actually  similar papers and work done in Nokia Research Center about
> > 4-5 years ago  to try to port SELinux to mobile devices. The output of
> > that work was mainly  that resource usage isn't acceptable for mobile
> > devices (this however maybe  not true for high-end devices now), but
> > also that building a proper working policy  for SELinux is far from
> > being an easy task. The guys in the paper just were  trying to squeeze
> > things to the appropriate sizes, but if you read the paper  carefully,
> > they don't' even claim that this policy will work in practice and will
> > provide security. In order to claim that one would really need to spend
> similar  effort like  for the reference policy design and what is more
> important verification.
> >  I don't say that this can't be done, but effort isn't going to be small
> by any means.

I do think that the resource constraints of enabling SELinux is far less
relevant for the class of devices we are targeting with MeeGo and will
become even less so with time.  I don't believe we would want to make
similar modifications to what Hitachi was looking at.

> SELinux as provided in distributions today does not, for all its
> trappings, complexity and assurances, enforce any security policy. SELinux
> is capable of enforcing a security policy, but no general purpose system
> available today provides anything more than a general description of the
> experienced behavior of a small subset of the system supplied
> applications.

Yes, but fortunately we are not in a position where we would need to provide
a SELinux policy for a general environment.  We would be providing one for
very specific environments.

> The people who built SELinux fell into a trap that has been claiming
> security developers since computers became programmable. The availability
> of granularity must not be assumed to imply that everything should be
> broken down into as fine a granularity as possible. The original Flask
> papers talk about a small number of well defined domains. Once the code
> was implemented however the granularity gremlins swarmed in and now the
> reference policy exceeds 900,000 lines. And it enforces nothing.

The Flask papers were conceived in an idealized world where many of our
current security problems hadn't yet been envisioned.  Don't you think that
the increasing granularity is due to those concepts coming into contact with
the real world?  

> All I've said here is that the issues Elena pointed out from the Hitachi
> paper are not unique to the embedded space. Even if SELinux did fit in
> your toaster do you want to define a million lines of fine grained policy
> description to make it work before you even start worrying about what your
> security issues might be?

No, you would always want to determine what your security issues are first.
However, that applies to whatever LSM MeeGo goes with.

> > >PS: Given the rescoping, why not improve the Android security model,
> > >which appears to be straightforward and implementable  (
> > >http://developer.android.com/guide/topics/security/security.html ).
> > >At least the security issues are being understood, the holes are
> > >being exposed. Perhaps an incremental but compatible improvement to
> > >the Android model could be considered? (  See
> > >http://lists.meego.com/pipermail/meego-security-discussion/2011-Janua
> > >ry/000019.html
> > >... ).
> 
> 
> > I have been studying Android security model a while ago and we
> > actually published  one paper this year about mobile OS comparison
> > with Android including, so if you  interested you can find it here:
> http://portal.acm.org/citation.cfm?id=1943517.
> >  The main difference for Android that all their permissions and
> > "caging" is done  by the Dalvik virtual machine, so if you go down to
> > plain Linux, there is nothing  there apart from DAC permissions. So,
> > in this sense you can say that it is simple :)  But Dalvik is in core
> > of Android itself, while MeeGo is so far doesn't have this  notion at
> all, so I don't think Android security model would apply for MeeGo case.
> 
> Don't go dismissing good old Unix DAC. User IDs and mode bits have been
> around so long that the value they provide is usually forgotten and when
> it is acknowledged they are rarely given the respect they are due. The
> only real shortcoming (I dismiss ACLs as a ploy set out by the granularity
> gremlins mentioned earlier) of classic Unix DAC is that the networking
> implementation failed to include it. If sockets did Unix DAC the issue of
> the day would be much reduced,

You'll get little argument from me here.  In MeeGo, we strongly under use
DAC and what we have is mostly there accidentally.  We have 24 users and 38
groups defined but that definition has not been done in any systematic way.
For example, do we really need a gopher group?  That said, we need more than
just DAC to fulfill all of our security requirements.

> > All in all, the main outcome of the paper was to show that all mobile
> > OS security  solutions are using the common principles and ideas, just
> > sometimes twisted in different ways based on OS architecture and
> > internal requirements. So, I would  say that same goes about MeeGo:
> > given its architecture, set of requirements  and apply the same basic
> > design principles, one can end up with very different  solutions
> > starting from MSSF and ending even with SELinux. Another question  is
> > where do we want to spend the most effort on while designing/developing
> this solution?
> 
> It would seem that for MeeGo there are three important rings of security.
> 
>  - The base MeeGo distributions
>    - MeeGo ARM
>  - The vendor shipped MeeGo platforn
>    - A toaster
>  - The 3rd party application for a MeeGo device
>    - The "Joy of Cooking" toast application
> 
> The distribution itself needs a security story, the vendor needs to make
> it work on her device, and the application needs to run on it within the
> bounds of what the vendor would allow.
> 
> I know SELinux has proven inaccessible to the vendor and the application
> writer.
> I also have a pretty good notion of how happy distribution vendors have
> been with it.

This has definitely been the case in the past, but I think this has been
changing.  That said, I think this is an issue for any LSM we choose.  Even
with Smack we will not have OEMs that have expertise with it and will need
education.

> Android on the other hand appears to be quite well received at all three
> levels.
> Caging is an isolation mechanism, and Smack is another. Hmmm.

I actually look at these two things as complementary and not competing.
Smack can offer Mandatory Access Controls while Linux Containers provides
process and network namespace separation.  The concern shouldn't be that
they can both be perceived as providing some type of isolation.  If only a
single isolation mechanism was enough, we wouldn't need to do anything but
run a process in ring 3.

Ryan