Though the document is indeed interesting and I invite everyone interested in security to read it. Elena again edited the wiki page with some more information about open / closed (normal) mode btw.

The wiki page doesn't seem to address policy - only technology, and the policy is the interesting thing. For example, as a matter of policy, will users with 'closed' mode devices be allowed to install software from maemo-extras?

Right :-) FWIW the other relevant-looking document that comes up when searching for linux and "mandatory access control" under nokia.com is this which talks about LIDS.

Anyway, although the actual mechanics of the implementation are interesting to geeks what we should be discussing openly is the policy to be implemented on top of these. There are already a few worrying things in the wiki discussion page (for example not being able to debug things on device will definitely hamper my bugzilla work). I understand the policies are not cast in stone yet, but that's exactly the right time to be discussing them.

Hi

Does anyone know if the summit video for the Maemo Security presentation is available now?

It is not listed here, but is the video hosted elsewhere?

Rich

Just like in any serious OSS conference, uploading the videos is taking longer than expected but we are working on it. :/

No problem, look forwading to see them all when ready.

Cheers
Rich

Yes, I hear uploading videos for silly conferences is a lot faster.

In principle it could make use of Linux containers to support "side by side" DRM and no-DRM environments, with "root" available to the no-DRM environment, but the no-DRM environment is limited in what it can do to the DRM environment.

The kernel of course could not be modified if you have a DRM environment running.

What I mean is that arrangement could support things like third party unsigned BlueZ PAN and DUN support which was mentioned. That would run in the no-DRM environment. As long as it doesn't need kernel changes, only system daemons, that could be made to work.

Even some third party open source kernel modules may be possible, if there's a way to isolate them by running them in a kernel in a VM guest which has controlled access to host subsystems and devices.

Ideally the security module keeping DRM and no-DRM sides apart, with only safe interactions, should stick to the bare minimum of necessary restrictions. Preferably choosing the restrictions based on what DRM-using apps require at the time.

For example, the no-DRM side should be able to intercept all network packets in and out and, say, run it through it's iptables or fancy routing/tunnelling, just as it can now on Maemo 5 as root; there is no reason to block that sort of thing.

But the no-DRM side would be blocked from modifying files that the DRM side says it requires to be signed and managed by signed programs (all the way down to the kernel), and if the no-DRM side changed any of those files (including the kernel) or break any other invariants requested by a DRM-using app, then the DRM side would see the signature for those invariants is not available.

In summary, there's some scope for more fine-grained side-by-side behaviour than simply booting into DRM vs. no-DRM modes. It can resemble more closely a finer grained traditional or role-based security module, with signatures for fine-grained invariants which DRM-using apps request, which are granted only of no apps is breaking them at the time (or might have broken them earlier, depending on the particular invariant). And switching between modes can be more fine grained too.

The one thing which seems unavoidable is third party open kernels may not be able to provide any invariants to DRM-using apps - unless there is some trick of the hardware which can do that which is beyond even the kernel to defeat.

I agree and think this could become a big issue fast.

Android has non-standard changes to Linux, I'm guessing to help address this sort of thing.

Fortunately Linux provides containers and they are getting almost mature now ;-) which could be used for sandboxing even quite low-level apps with no significant loss in performance. For most apps, I'd expect they could run in a container quite well. They can still share libraries (Gtk, Qt etc.), including sharing the memory at run time with code outside the container or in other containers, and sharing config files, if the files are managed well.