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.