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

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.

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.

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.

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 (which I found through the lwn article Quim linked to) 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?


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")