View Full Version : Maemo 6 Platform Security
Hey people,
I wasn't at FOSDEM, so I wasn't able to listen to Elena talk, nor chat with her. I'm still quite interested by Maemo 6 Security features, so it'd be nice if some people which were there (or Elena) could do a summary.
Are the slides online somewhere, and is there some kind of video footage?
I noticed there was a new Maemo 6 Platform Security (http://maemo.gitorious.org/maemo-6-platform-security) project at gitorious, so I guess it's related.
Have you seen the slides etc. from the summit?
http://wiki.maemo.org/Maemo_security
Yes, and I helped cooking the Maemo Security (http://wiki.maemo.org/MaemoSecurity) wiki page. Now I was looking for more information, since I guess the new talk wasn't just a repetition of the summit talk?
I'm a plonker. Official.
ehehe :) :p
Anyway, I am also interested in this topic.
There a bit more info in this interview: http://fosdem.org/2010/interview/elena-reshetova
catalin.hritcu
2010-02-10, 14:41
I attended and it was a very nice talk! Hope that the video will be online soon so that you can also enjoy :)
Just remember: it's "security," but not for you.
GeneralAntilles
2010-02-10, 19:37
Just remember: it's "security," but not for you.
Actually, it is, the Maemo 6 framework will allow you to encrypt personal information on the device.
That would be a significant improvement. The wiki page linked above is bereft on anything regarding that, focusing mainly on the DRM aspect.
Just remember: it's "security," but not for you.
I'm interested on the security platform as a security researcher, not only for my own usage. So I'm more interested about what can be done to secure usage in both private and business uses.
Interested in how “hardened” the device is (stuff like address randomization, W^X, etc.)
FOSDEM'10: Maemo 6 platform security
http://lwn.net/SubscriberLink/373780/1b98fb582ab0249c/
(LWN subscriber-only content - let me pay this off with a little advertisement below)
Welcome to LWN.net
The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!
Thanks! (fortunately for me, since I'm a Debian developer, I have a LWN account)
benny1967
2010-02-11, 07:30
thx for the link; i have to admit i was worried about the restrictions management in M6, but this one paragraph makes me happy:
Users can also switch between the open and closed modes (e.g. between a 'community' kernel and Nokia's kernel), so that after working in the open mode, users can return to the DRM-protected mode to play some music. If the application doesn't use the protected storage but just stores its data as plain files in the file system, like most non-commercial applications will do, those files are accessible in both modes. Switching modes requires rebooting the device, though, because the checks for the integrity of the software are done by the boot loader.
previous documentation had made it clear users could switch from one mode to another. this is the first time i read users can switch back and forth and that unrestricted files will be available in both modes. (another possibility would have been that once you un-DRMed your device, you couldn't get back to "comes with music"-mode... or that your own non-DRMed photos aren't accessible in open mode when you shot them in restricted mode. all of that doesn't seem to be the case.)
the article is interesting for end users like me, too, not only for developers.
Does the N900 have the "hardware enabler: the ARM TrustZone security extension to the ARM Cortex-A8 processor" mentioned in that LWN.net article?
Does the N900 have the "hardware enabler: the ARM TrustZone security extension to the ARM Cortex-A8 processor" mentioned in that LWN.net article?
Yes. Well, at least it should, though I didn't check by myself.
Elena Reshetova
2010-02-11, 17:11
Hi,
Sorry for the delay. I uploaded the presentation here:
http://www.slideshare.net/reshetov/maemo-platform-security-fosdem
The video of the presentation should be soon available on FOSDEM site.
mannakiosk
2010-02-12, 11:29
there are videos from fosdem 10 up now at http://video.fosdem.org/
Elena Reshetovas talk "Maemo 6 Platform Security": http://video.fosdem.org/2010/maintracks/maemo.xvid.avi
Talking about user restrictions of a future release of Maemo might not be the best move especially if you use marketing terms as PC-like and OpenSource.
Good luck dealing with GPLv3.
i have to admit i was worried about the restrictions management in M6, but this one paragraph makes me happy:
Heh, it didn't relieve me. It's all very unspecific. Also, can I set up bootloader to boot into "open mode" by default? Or I'll have to press 10 different keys on every boot to activate it?
I'm kind of disappointed by Nokia. And not only in just that implementation of "trusted computing" (it maybe not that bad, I don't know, please give us some more real details), but mostly I'm disappointed by the trend.
Trusted computing?
http://www.youtube.com/watch?v=U0FAaah8jgY
No, thanks.
I really hate DRM and everything around it
Talking about user restrictions of a future release of Maemo might not be the best move especially if you use marketing terms as PC-like and OpenSource.
Good luck dealing with GPLv3.
Well - that is if you are targetting GPLv3. I seem to recall this question coming up at the Maemo 6 security talk in Amsterdam. Peter got up right away, and confirmed that Maemo 6 would be GPLv2 compliant.
(from my recollection - please correct me if I was wrong in my understanding)
Well - that is if you are targetting GPLv3. I seem to recall this question coming up at the Maemo 6 security talk in Amsterdam. Peter got up right away, and confirmed that Maemo 6 would be GPLv2 compliant.
(from my recollection - please correct me if I was wrong in my understanding)
So, there won't be most of up to date GNU software? Because, well, gnu.org pushed (L)GPLv3 to most of their projects.
Well - that is if you are targetting GPLv3. I seem to recall this question coming up at the Maemo 6 security talk in Amsterdam. Peter got up right away, and confirmed that Maemo 6 would be GPLv2 compliant.
(from my recollection - please correct me if I was wrong in my understanding)
from my recollection he replied to the guy from osm2go (sorry don't remember his name), who brought up that elenas speech gave him concern to believe that harmattan may be incompatible with gplv3. peter's reply went something along the lines of "...then we will not use gplv3". but i have a fuzzy memory too.
Stskeeps
2010-02-12, 15:58
There's no GPLv3 code in Maemo, afaik.
This DRM thingy scares me a lot. Even though i don't think Maemo will go like Apple all the way. It seams to going towards being less free. There is little point for me to have Maemo if it is not free. Maybe Mer would suit me better.
This feel like they want to raise security for software developers. Not for the goods of users. I am a donator and a filesharer not a buyer.
Elena did not give an answer on that last question in the FOSDEM-video. If it will impact the possibility to install other OS's. Cause if this is taking an direction i do not like i would like to have the possibility to install Lubuntu or something.
mannakiosk
2010-02-12, 21:42
gpl2 and gpl3 and proprietary code can coexist fine.
as long as i can have access to phone and location api:s and whatnot in the open kernel mode, all is just fine and dandy, technologically. All they are going to restrict me, the user, from is the drm that I don't want anyway, right?
Hmm, the wiki (http://wiki.maemo.org/Talk:MaemoSecurity) (which I found through the lwn article Quim linked to (http://talk.maemo.org/showthread.php?t=43627&highlight=security+harmattan&page=2)) says this is the place to discuss things but its been quiet for a while. Hopefully this is till the place.
Passwords
Also a fun thing for those concerned about passwords, RTComm sends passwords in plain text over DBus to Telepathy Connection Managers. In debugging The One Ring, I sometimes ask for sample runs of "dbus-monitor --session > log" and people either don't know to censor their password or forget. (I hate knowing peoples passwords so I avoid them as much as possible). Any application can listen for dbus signals from RTComm that include passwords and collect them.
Maemo 6 Security
Pertaining to the security policy, I also feel uneasy. I love the idea of per-process privileges. I just worry about the hackability, the ability to say "No, I really know what I'm doing" or "qwerty12 is a solid guy, I trust him. He said this was ready for use, so I'll use it".
My concerns and Questions:
Is any of the Aegis privilege system enabled on Open Mode? If not, that stinks because it means reduced security for the open people. If so, how is it exposed to the user by default? Can the user chose to override anything? Do we have to custom build stuff to get user overriding, reducing the out-of-box hackability?
Lack of user control in "normal" mode. I love being able to debug my application on the fly, grabbing what data I need. I also love what all this community has generated and worry about how this will end up restricted.
An example where this could be a serious issue. Let's say a company released a program with a plugin architecture, like RTComm, but its distributed through Ovi. Debugging it is a weird situation because companies wouldn't want random people running debuggers on their applications because that can be used to crack them. So to simplify the example, let's say it does out-of-process plugins (even more like RTComm). I've been working on a GV plugin to RTComm. With Empathy and Maemo 4.1 (but not Maemo 5) I've caused instigated crashes while still being out of process and I've ignored messages I shouldn't have and forgotten to send messages I should. I'd want to run a debugger or monitor dbus to know what is going wrong. Unfortunately debugging tools only work in "open mode" but the companies application I'm plugging in to is only available in "normal mode".
More debugging: The FOSDEM slides mention the Integrity checker. I write python apps and get value out of being able to change them on the fly. So in "normal" mode, even if I was in an app with the write privelages, I couldn't do it?
Is there privilege inheritance, like say I do I system call "cp FILE PATH", will cp inherit my app's privileges and be able to do the writes if my app is able to?
With privilege inheritance, we could have a command prompt at max privileges and then you can run your debugger and anything else. This would allow the user to override things while the apps can't do privilege escalation to run debuggers on other apps or other nasty things.
I worry that Maemo will split into two communities, "iPhone"-users and Maemo-users. If these two communities are too incompatible then one will end up suffocating the other due to "must have" features (OVI apps or community hacks).
On a related note: Even with warnings we have people see the cool hacks, enable extras-testing or extras-devel, and play around. So the early adopters are all running in open mode to get these cool things. When their friends get it, the early adopters set this stuff up for them. Eventually the "open mode" community suffocates the "normal mode" community. So no one can use DRM (yay) but where do we now stand in terms of security? How much of the work done has been for naught?
More of a community logistics question but what will we do on the mailing lists, t.m.o, wiki, etc about this split community?
PPS. I spoke to Niels immediately after Elena's talk and there are two useful things we can do on Downloads (http://maemo.org/downloads/) and/or Packages (http://maemo.org/packages/): showing the capabilities requested by a package (by parsing its Aegis manifest) whilst a user is browsing the apps (before having to install it), and making the autobuilder check that an app doesn't request any privileges which aren't available to apps available through Extras.
If the autobuilder enforces "normal mode" privilege restrictions, this would imply Extras could not host apps destined only for Open Mode. Would the community have a "Secure Extras" and "Extras Hacks" to separate the restricted and unrestricted apps?
How does the SDK determine what privileges my app needs? Is it language dependent? depend on what libraries you are using symbols from? What if I'm talking to dbus directly? I'm assuming you can always write your own aegis file if the SDK gets it wrong.
I know she listed the restricted resources as examples but I saw rootfs included. In an ideal world and Maemo 5's current format, no community thing would ever be installed there and it wouldn't be an issue. The problem is when you need to plugin to applications like RTComm requiring some files to be in a certain location or registering your DBus service. Yes alternative locations would be made but (1) that breaks apps in yet another way between Linux/Maemo and even versions of Maemo, (2) it would end up being reactionary ("drat, Nokia missed a plugin I need to register to, time to file a bug and wait a couple months for an SSU").
An option for abating this would to instead of having an "/opt" for the community, have a "/secure" for Nokia. All standard Linux paths would map to outside of "rootfs" and work as expected. They would then selectively put things in "rootfs" that they knew required security (like /boot). being more selective of what is put in rootfs. This would also remove the need to "optify" an application.
Hmm, I hope I covered my thoughts while not being too confusing.
I think the following items would allow everyone to run in the same mode and still satisfy the security/DRM requirements.
As mentioned in my previous post, the command prompt runs at the highest privileges with privilege inheritance for the programs the user spawns
Programs required special privilege to modify other programs
We just offer even bigger fat warnings when installing an app that requires such privilege, requiring the user to type in "I acknowledge surrendering my soul" to accept
We just produce a one-time "Zombies Ahead" warnings (instead of errors) when a package's signature (OS or user) fails to match
How much security would this cause us to lose? What other positive or negative impact might it have?
Examples of how DRM would break
Modify kernel, gstreamer, etc to capture music
Remove the checks on OVI apps so they run even if you copied them from a different device
I do admit and shed no tears that DRM could be broken with this model, but this is about a security framework and showing respect to your customer rather than living in late-90s early 200X's and treating your customer like "the evil hard-bitten criminal scum that [they] are" (Weird Al's "Don't Download This Song")
I saw reference to having patches for DBus available. How much are you working with kernel, dbus, DEs, other security model implementers, and Distributions?
Are they willing to merge the idea? the implementation? It could be a huge cost if upstream requires backwards incompatible changes to be accepted. It is also a huge cost to Nokia and the users to always be running a fork.
Are desktop distributions interested in using the security model? Is there interest or consensus from other security implementers (app armor, selinux, etc?
Hi, I have some questions maybe they have already been answered I shall work though all these threads and pages on the subject I have found.
* What is the best email address (or method of contact) to the Nokia Security team that is working on this ?
* Which product does the team believe this shall be released into, Maemo6 or Meego1 (or both - i.e. FOSDEM was before/around the Meego announcement and I'm working towards Meego to see if some of my requirements can be added to the platform) ?
* The community require to make use of all features of "closed mode" where there is a common goal (for example the purpose of providing rootkit protection for users of alternative kernels but those users are not themselves developers). For this there would need to be the ability to set and store a few additional cryptographic keys provided by the user (presumably in "open mode" to do that), the verification code (in NOLO) needs to optimally select the correct key to perform verification with for the image it is loading (verfiying each key found in a locally stored repoistory until you get a match maybe too slow at bootup!) and there would need to be at least one additional mode to mean "any verifed kernel image". Where "closed mode" (aka "vendor mode") would only boot images that verfiied with a vendors (hidden/closed/secret/immutable to community) key. These would be features of NOLO, since the trusted execution needs to start from there, this means Nokia would need to provide details/documentation of how that works to the community. Alternatively the community die hards would need to seek to replace NOLO (because the feature of Trusted Execution would not be available to them otherwise).
* There is a specific Threat Model to mobile devices that the current Maemo5 (from what I can see) does not seem to address. That is providing fine granularity over the protections and lockouts of the device. To address this the device need to provide some basic assurances:
** Any keys that are changed, there must be assurance the old key is destroyed (this is not true of N900, and a special problem for flash devices that level-wear). If you are going to move the flash storage block where the security key data WAS stored, then you must erase/rewrite/destory the old copy of the key (once you are happy you committed the new copy sucessfully). So key scrubbing for this one.
** It is known that the Modem unit inside the phone has storage available inside it, are the methods for accessing and using that storage available to the community ?
** Users must be able to make their device worthless when stolen, both in terms of data content and in terms of not allowing a thief to reflash the phone to resell it (they are flagship products). Also included in this is the ability to lockdown the entire device hardware (i.e. requires unlock code on power up) when a Mobile Network Operator barrs the SIM from registering on the network. All this when combined with handset to SIM card locking (common in many other Nokia products) provides a pretty watertight way to an owner making theft ineffective.
** Bulk data security is already well understood and would be the next features to be added after the groundwork (listed above) is in place. This is not a priority while the above basic stuff still needs attention.
As for the new APIs added by the Maemo Security team (as outlined at FOSDEM) it all sounds very good for other stake holders (who are not actually the phone end-users). I can only presume that your bulk buying customers (i.e. Mobile Network Operators) are pushing for these features in order to purchase the next model. I can also understand the commercial application interest too in the APIs for licensing/DRM and such so from that standpoint the higher layer parts the FOSDEM talk all make sense.
So whatever is implemented could the mechanisms be just as available for use by the community as they are for Nokia, MNOs and DRM application writers ? This starts by allowing a community kernel to be signed by a community key and for the end-user to have peace of mind that trusted execution is still at work. Rootkits would be bad news for the platform.
The meego-dev mailing list is probably a more appropriate place to reach the developers and have a technical discussion now that MeeGo is the primary target distribution for this security framework.
If you want to contact the developers http://meego.gitorious.org/meego-platform-security gives you a direct path.
vBulletin® v3.8.8, Copyright ©2000-2024, vBulletin Solutions, Inc.