Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: <casey.schaufler-xNZwKgViW5gAvxtiuMwx3w <at> public.gmane.org>
Subject: Re: Arbitrary 3rd Party Code
Newsgroups: gmane.comp.handhelds.meego.security.general
Date: Thursday 7th April 2011 15:24:12 UTC (over 6 years ago)
________________________________________
From: Reshetova Elena (Nokia-SD/Helsinki)
Sent: Thursday, April 07, 2011 12:23 AM
To: ext Niels Mayer; Schaufler Casey (Nokia-SD/SiliconValley);
[email protected]
Cc: [email protected]g
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.

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.

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.

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?


> >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-January/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,

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

> Best Regards,
> Elena.



-----Original Message-----
From:
[email protected]gmane.org
[mailto:[email protected]gmane.org]
On Behalf Of ext Niels Mayer
Sent: 07 April, 2011 09:47
To: Schaufler Casey (Nokia-SD/SiliconValley);
ware-VuQAYsv1563Yd54FQh9/[email protected]
Cc: [email protected]g
Subject: Re: [Meego-security-discussion] Arbitrary 3rd Party Code

Regarding SELinux,

FYI, in http://lists.meego.com/pipermail/meego-dev/2011-January/481207.html
I noted:
"An interesting counterpoint:
http://ols.fedoraproject.org/OLS/Reprints-2008/nakamura-reprint.pdf
is
suggested in
http://lwn.net/Articles/293075/
"

Any comments on the findings in the aforementioned paper
"SELinux for Consumer Electronics Devices"
(Yuichi Nakamura and Yoshiki Sameshima, Hitachi Software Engineering) ?

Niels
http://nielsmayer.com

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-January/000019.html
... ).
_______________________________________________
MeeGo-security-discussion mailing list
[email protected]g
http://lists.meego.com/listinfo/meego-security-discussion
 
CD: 3ms