Defining a Maemo security policy

February 18, 2009

I’m no expert on security. As a debian GNU/Linux user I have been spoiled by a dedicated security team that looks after all the packages in debian, both stable and testing, so I don’t have to be an expert in security. I just rely on the security team to keep me updated.

I have done a little security work however and I understand how difficult it is, especially when you have a complex system. One of the mantras that I hear is “security is a process.” I think this is true, security is a process, not just an add-on or a patch. Security has to be thought of from the beginning through development to deployment – not just when the end user has it in their hands and is started to hack on it.

I would like to tap into the views and expertise of the community and try to establish a discussion around security in Maemo and in its ecosystem. Since Maemo is built upon a foundation (Debian) known for stability and technical quality, Maemo inherits some of Debian’s infrastructure regarding security. But what more could be done? Furthermore, what should be done?

I hope that we can bring forth the ‘best practices’ and innovations that the community around Maemo has, develop methods to protect users, maybe even hammer out policy. But all of this has to be done in the open I feel, it has to be driven by the community.

So what do you think? Do you worry about exploits? Do you test your code for buffer overflows or run it through valgrind? What would a Maemo security team look like? How does one balance open access with system integrity?

I look forward to the discussion.

EDIT: More info on Maemo security policy here.

One Response to “Defining a Maemo security policy”

  1. Hmmm, tough question(s)

    One thing that pops from my stack is close by default. The less services and ports that are open by default and actively, yet easy, has to be opened manually the better start we have.