|| ||<casey.schaufler-xNZwKgViW5gAvxtiuMwx3w-AT-public.gmane.org> |
|| ||<elena.reshetova-xNZwKgViW5gAvxtiuMwx3w-AT-public.gmane.org>, <nielsmayer-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org>, <ware-VuQAYsv1563Yd54FQh9/CA-AT-public.gmane.org> |
|| ||Re: Arbitrary 3rd Party Code |
|| ||Thu, 7 Apr 2011 15:24:12 +0000|
|| ||Article, Thread
From: Reshetova Elena (Nokia-SD/Helsinki)
Sent: Thursday, April 07, 2011 12:23 AM
To: ext Niels Mayer; Schaufler Casey (Nokia-SD/SiliconValley); email@example.com
Subject: RE: [Meego-security-discussion] Arbitrary 3rd Party Code
> > 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/securi... ). 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
> >... ).
> 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
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,
[mailto:meego-security-discussion-bounces-VVXm0OgCXj10cC2W... On Behalf Of ext
Sent: 07 April, 2011 09:47
To: Schaufler Casey (Nokia-SD/SiliconValley); ware-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
Subject: Re: [Meego-security-discussion] Arbitrary 3rd Party Code
FYI, in http://lists.meego.com/pipermail/meego-dev/2011-January/4...
"An interesting counterpoint:
Any comments on the findings in the aforementioned paper
"SELinux for Consumer Electronics Devices"
(Yuichi Nakamura and Yoshiki Sameshima, Hitachi Software Engineering) ?
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/securi... ). 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
MeeGo-security-discussion mailing list
to post comments)