One of the things that has come up in some of the recent discussions is what are we trying to do at a high-level. I'd like to use a methodology I've used in the past that will help put this together for everyone. This methodology uses high-level statements that define the security goals of the project. These goals themselves are not requirements but security requirements should be able to trace themselves to one or more of the security goals.
Additionally, along with security goals I would like to identify security non-goals. These non-goals are statements about things are security solution specifically will not protect from. These goals are not for 1.2 but are for the 1.3 - 1.4 timeline. Security Goals: * MeeGo shall enable end-users to control which applications are allowed to access their personal data. (End-users should be able to protect their privacy) * MeeGo shall include protections to reduce the possibility and potential impact of privilege escalation attacks. (Privilege escalation attacks will happen but we want to limit the number of them as well as what they can do if they are successful.) * MeeGo security solutions shall be part of the MeeGo compliance stack and available for all verticals. Verticals will each have their own security configurations. (This does not mean all verticals will be forced to have all security components enabled. It just means they are there to be used depending on the vertical security requirements. * MeeGo shall enable additional protections for sensitive platform resources (cellular, GPS, etc.) * MeeGo shall enable access controls allowing finer granularity than standard DAC. (While DAC has many good qualities, it is not sufficient in and of itself.) * MeeGo shall support secure (measured) boot for environments that require extending the HW root-of-trust to the software stack. (Some verticals have requirements to require knowing what software stack is on the platform). * MeeGo shall include update mechanisms that are secure and enable overwrite protections for trusted applications. (Need to know where software updates come from, that they haven't been tampered with and that "Joe's Appstore" cannot add it's own version of MeeGo compliance packages.) * MeeGo shall provide a unified SSO solution that allows the end-user centralized control of credentials for all network services (IM/mail/etc.) * MeeGo shall include mechanisms to help protect the integrity of data storage. * MeeGo shall enable HW security protections where available on targeted platforms. * MeeGo shall comply with all MeeGo security policies. (These will be made available separately). * MeeGo shall include the ability to meet protected content robustness requirements for specific supported platforms. (There are some verticals that require the ability to protect content.) Security Non-Goals: * MeeGo shall not try and be Fort Knox. (MeeGo and MeeGo devices will never be impervious to attack nor do our requirements demand that we be.) * MeeGo shall not prevent successful user to root or unprivileged (ring 3) to privileged (ring 0) privilege escalation attacks. (There will always be software bugs that enable these.) * MeeGo shall not prevent successful physical attacks. There are more goals above than I would typically like, but MeeGo is a fairly unique beast. What are your thoughts on the above? Does it cover or not cover areas you would expect? Are there other non-goals that you think I'm missing? Ryan _______________________________________________ MeeGo-security-discussion mailing list [email protected] http://lists.meego.com/listinfo/meego-security-discussion
