MeeGo wiki - User contributions [en]

Security/Architecture

2011-06-27T21:26:54Z

Ryanware: /* This page no longer current. Will be updated in the near future. */

==This page includes all references to MeeGo Security Architecture content.==

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to all of the MSSF Architecture Team.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

{| class="wikitable" style="text-align: center" border="1"
|+ Simple Device Policy Example
|-
! scope="col" | SW Source Name
! scope="col" | Trust Level
! scope="col" | Public Key Info
! scope="col" | Possible Credentials
|-
| MeeGo.com || 100 || <code>ABCDEF...</code> || Cellular, UserData
|-
| Developer.org || 20 || <code>ACDEFC...</code> || UserData
|-
| Unknown || 10 || <code>---------</code> || UserData
|}

=== Certificate Manager ===

The MSSF Certificate Manager subsystem provides means of managing and securely storing the system’s X.509 signing certificates, user’s own certificates and the related private keys. These certificates can be used by various applications in MeeGo (like browser, e-mail and other applications) in order to perform authentication of the remote party or, in case of user’s certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manager subsystem is a libmssf-certman library, which provides a user space interface for MeeGo applications in order to perform actions described above.

When authenticating a remote service (for example, web site or mail server), an application usually needs to be able to verify an X.509 signing certificate, presented by this service. In order to do it, it needs to verify an authority, which signed this certificate. This, in turn, can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate. However, such a chain of certificates can’t be endless and therefore some certificates in this chain are usually self-signed certificates (also called root certificates), which are initially imported to the system and trusted by it. So, in order to verify a remote service’s certificate, an application needs to retrieve a set of system’s self-signed root X.509 certificates and verify the presented certificate against this set via some certificate chain. This use case is shown in Figure 6. A browser application received an X.509 certificate and needs to validate it. In order to do it, it uses the libmssf-certman interface:

[[Image:MSSF_Certman_Interaction_Cert_Retrieval.png|350 px|Certificate Manager high-level interaction view (Certificate retrieval)]]

# To ask the libmssf-certman for the set of the system’s self-signed certificates
# Libmssf-certman requests libmssf-crypt to verify the integrity of the certificate store
# The system’s cryptographic services verify the integrity
# If there is no compromise, libmssf-certman is notified
# The set of certificates is returned to the browser

Another typical use case for the libmssf-certman usage is handling of a user’s private keys that can be used to authenticate a user and user’s data to a remote service. This use case is shown in Figure 7. An e-mail application would like to sign a user’s email and therefore needs the user’s private key which is stored in the certificate manager.

[[Image:MSSF_Certman_Interaction_Privkey_Retrieval.png|350 px|Certificate Manager high-level interaction view (Private Key Retrieval)]]

# It requests the private key via libmssf-certman
# Which checks the protection method for the requested private key
# If the key is protected with a user passphrase, libmssf-certman requests it from the e-mail application
# The e-mail application requests the passphrase from the user
# The passphrase is passed to libmssf-certman by the e-mail application
# Which decrypts the private key and returns it to the e-mail application

The libmssf-certman library also implements a standard PKCS#11 interface to manage X.509 certificates. This allows usage of the Certificate Manager subsystem for applications that can’t be changed in order to use the libmssf-certman interface directly.

= External Documentation =

== MeeGo 2010 Conference ==

* [http://conference2010.meego.com/session/meego-security-what-it-and-why-do-we-care MeeGo Security: What is it and why do we care?]
* [http://conference2010.meego.com/session/mobile-simplified-security-framework-overview Mobile Simplified Security Framework Overview]
* [http://conference2010.meego.com/session/cost-security-developers-view The Cost Of Security, A Developer's View]

== Publications ==

* Mobile Simplified Security Framework, Linux Symposium paper, [[File:MSSF_OLS2010.pdf]]
* Mobile Simplified Security Framework, Linux Symposium slides, [[File:MSSF_Slides_OLS2010.pdf]]

Security/Architecture

2011-06-06T20:04:26Z

Ryanware:

== This page no longer current. Will be updated in the near future. ==

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to all of the MSSF Architecture Team.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

{| class="wikitable" style="text-align: center" border="1"
|+ Simple Device Policy Example
|-
! scope="col" | SW Source Name
! scope="col" | Trust Level
! scope="col" | Public Key Info
! scope="col" | Possible Credentials
|-
| MeeGo.com || 100 || <code>ABCDEF...</code> || Cellular, UserData
|-
| Developer.org || 20 || <code>ACDEFC...</code> || UserData
|-
| Unknown || 10 || <code>---------</code> || UserData
|}

=== Certificate Manager ===

The MSSF Certificate Manager subsystem provides means of managing and securely storing the system’s X.509 signing certificates, user’s own certificates and the related private keys. These certificates can be used by various applications in MeeGo (like browser, e-mail and other applications) in order to perform authentication of the remote party or, in case of user’s certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manager subsystem is a libmssf-certman library, which provides a user space interface for MeeGo applications in order to perform actions described above.

When authenticating a remote service (for example, web site or mail server), an application usually needs to be able to verify an X.509 signing certificate, presented by this service. In order to do it, it needs to verify an authority, which signed this certificate. This, in turn, can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate. However, such a chain of certificates can’t be endless and therefore some certificates in this chain are usually self-signed certificates (also called root certificates), which are initially imported to the system and trusted by it. So, in order to verify a remote service’s certificate, an application needs to retrieve a set of system’s self-signed root X.509 certificates and verify the presented certificate against this set via some certificate chain. This use case is shown in Figure 6. A browser application received an X.509 certificate and needs to validate it. In order to do it, it uses the libmssf-certman interface:

[[Image:MSSF_Certman_Interaction_Cert_Retrieval.png|350 px|Certificate Manager high-level interaction view (Certificate retrieval)]]

# To ask the libmssf-certman for the set of the system’s self-signed certificates
# Libmssf-certman requests libmssf-crypt to verify the integrity of the certificate store
# The system’s cryptographic services verify the integrity
# If there is no compromise, libmssf-certman is notified
# The set of certificates is returned to the browser

Another typical use case for the libmssf-certman usage is handling of a user’s private keys that can be used to authenticate a user and user’s data to a remote service. This use case is shown in Figure 7. An e-mail application would like to sign a user’s email and therefore needs the user’s private key which is stored in the certificate manager.

[[Image:MSSF_Certman_Interaction_Privkey_Retrieval.png|350 px|Certificate Manager high-level interaction view (Private Key Retrieval)]]

# It requests the private key via libmssf-certman
# Which checks the protection method for the requested private key
# If the key is protected with a user passphrase, libmssf-certman requests it from the e-mail application
# The e-mail application requests the passphrase from the user
# The passphrase is passed to libmssf-certman by the e-mail application
# Which decrypts the private key and returns it to the e-mail application

The libmssf-certman library also implements a standard PKCS#11 interface to manage X.509 certificates. This allows usage of the Certificate Manager subsystem for applications that can’t be changed in order to use the libmssf-certman interface directly.

= External Documentation =

== MeeGo 2010 Conference ==

* [http://conference2010.meego.com/session/meego-security-what-it-and-why-do-we-care MeeGo Security: What is it and why do we care?]
* [http://conference2010.meego.com/session/mobile-simplified-security-framework-overview Mobile Simplified Security Framework Overview]
* [http://conference2010.meego.com/session/cost-security-developers-view The Cost Of Security, A Developer's View]

== Publications ==

* Mobile Simplified Security Framework, Linux Symposium paper, [[File:MSSF_OLS2010.pdf]]
* Mobile Simplified Security Framework, Linux Symposium slides, [[File:MSSF_Slides_OLS2010.pdf]]

Security/Architecture

2011-02-03T16:19:07Z

Ryanware: /* MeeGo Security Architecture */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to all of the MSSF Architecture Team.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

{| class="wikitable" style="text-align: center" border="1"
|+ Simple Device Policy Example
|-
! scope="col" | SW Source Name
! scope="col" | Trust Level
! scope="col" | Public Key Info
! scope="col" | Possible Credentials
|-
| MeeGo.com || 100 || <code>ABCDEF...</code> || Cellular, UserData
|-
| Developer.org || 20 || <code>ACDEFC...</code> || UserData
|-
| Unknown || 10 || <code>---------</code> || UserData
|}

=== Certificate Manager ===

The MSSF Certificate Manager subsystem provides means of managing and securely storing the system’s X.509 signing certificates, user’s own certificates and the related private keys. These certificates can be used by various applications in MeeGo (like browser, e-mail and other applications) in order to perform authentication of the remote party or, in case of user’s certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manager subsystem is a libmssf-certman library, which provides a user space interface for MeeGo applications in order to perform actions described above.

When authenticating a remote service (for example, web site or mail server), an application usually needs to be able to verify an X.509 signing certificate, presented by this service. In order to do it, it needs to verify an authority, which signed this certificate. This, in turn, can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate. However, such a chain of certificates can’t be endless and therefore some certificates in this chain are usually self-signed certificates (also called root certificates), which are initially imported to the system and trusted by it. So, in order to verify a remote service’s certificate, an application needs to retrieve a set of system’s self-signed root X.509 certificates and verify the presented certificate against this set via some certificate chain. This use case is shown in Figure 6. A browser application received an X.509 certificate and needs to validate it. In order to do it, it uses the libmssf-certman interface:

[[Image:MSSF_Certman_Interaction_Cert_Retrieval.png|350 px|Certificate Manager high-level interaction view (Certificate retrieval)]]

# To ask the libmssf-certman for the set of the system’s self-signed certificates
# Libmssf-certman requests libmssf-crypt to verify the integrity of the certificate store
# The system’s cryptographic services verify the integrity
# If there is no compromise, libmssf-certman is notified
# The set of certificates is returned to the browser

Another typical use case for the libmssf-certman usage is handling of a user’s private keys that can be used to authenticate a user and user’s data to a remote service. This use case is shown in Figure 7. An e-mail application would like to sign a user’s email and therefore needs the user’s private key which is stored in the certificate manager.

[[Image:MSSF_Certman_Interaction_Privkey_Retrieval.png|350 px|Certificate Manager high-level interaction view (Private Key Retrieval)]]

# It requests the private key via libmssf-certman
# Which checks the protection method for the requested private key
# If the key is protected with a user passphrase, libmssf-certman requests it from the e-mail application
# The e-mail application requests the passphrase from the user
# The passphrase is passed to libmssf-certman by the e-mail application
# Which decrypts the private key and returns it to the e-mail application

The libmssf-certman library also implements a standard PKCS#11 interface to manage X.509 certificates. This allows usage of the Certificate Manager subsystem for applications that can’t be changed in order to use the libmssf-certman interface directly.

= External Documentation =

== MeeGo 2010 Conference ==

* [http://conference2010.meego.com/session/meego-security-what-it-and-why-do-we-care MeeGo Security: What is it and why do we care?]
* [http://conference2010.meego.com/session/mobile-simplified-security-framework-overview Mobile Simplified Security Framework Overview]
* [http://conference2010.meego.com/session/cost-security-developers-view The Cost Of Security, A Developer's View]

== Publications ==

* Mobile Simplified Security Framework, Linux Symposium paper, [[File:MSSF_OLS2010.pdf]]
* Mobile Simplified Security Framework, Linux Symposium slides, [[File:MSSF_Slides_OLS2010.pdf]]

Security/Architecture

2011-02-02T22:17:03Z

Ryanware: /* MeeGo Security Architecture */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler, Ilhan Gurel, Dmitry Kasatkin and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

{| class="wikitable" style="text-align: center" border="1"
|+ Simple Device Policy Example
|-
! scope="col" | SW Source Name
! scope="col" | Trust Level
! scope="col" | Public Key Info
! scope="col" | Possible Credentials
|-
| MeeGo.com || 100 || <code>ABCDEF...</code> || Cellular, UserData
|-
| Developer.org || 20 || <code>ACDEFC...</code> || UserData
|-
| Unknown || 10 || <code>---------</code> || UserData
|}

=== Certificate Manager ===

The MSSF Certificate Manager subsystem provides means of managing and securely storing the system’s X.509 signing certificates, user’s own certificates and the related private keys. These certificates can be used by various applications in MeeGo (like browser, e-mail and other applications) in order to perform authentication of the remote party or, in case of user’s certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manager subsystem is a libmssf-certman library, which provides a user space interface for MeeGo applications in order to perform actions described above.

When authenticating a remote service (for example, web site or mail server), an application usually needs to be able to verify an X.509 signing certificate, presented by this service. In order to do it, it needs to verify an authority, which signed this certificate. This, in turn, can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate. However, such a chain of certificates can’t be endless and therefore some certificates in this chain are usually self-signed certificates (also called root certificates), which are initially imported to the system and trusted by it. So, in order to verify a remote service’s certificate, an application needs to retrieve a set of system’s self-signed root X.509 certificates and verify the presented certificate against this set via some certificate chain. This use case is shown in Figure 6. A browser application received an X.509 certificate and needs to validate it. In order to do it, it uses the libmssf-certman interface:

[[Image:MSSF_Certman_Interaction_Cert_Retrieval.png|350 px|Certificate Manager high-level interaction view (Certificate retrieval)]]

# To ask the libmssf-certman for the set of the system’s self-signed certificates
# Libmssf-certman requests libmssf-crypt to verify the integrity of the certificate store
# The system’s cryptographic services verify the integrity
# If there is no compromise, libmssf-certman is notified
# The set of certificates is returned to the browser

Another typical use case for the libmssf-certman usage is handling of a user’s private keys that can be used to authenticate a user and user’s data to a remote service. This use case is shown in Figure 7. An e-mail application would like to sign a user’s email and therefore needs the user’s private key which is stored in the certificate manager.

[[Image:MSSF_Certman_Interaction_Privkey_Retrieval.png|350 px|Certificate Manager high-level interaction view (Private Key Retrieval)]]

# It requests the private key via libmssf-certman
# Which checks the protection method for the requested private key
# If the key is protected with a user passphrase, libmssf-certman requests it from the e-mail application
# The e-mail application requests the passphrase from the user
# The passphrase is passed to libmssf-certman by the e-mail application
# Which decrypts the private key and returns it to the e-mail application

The libmssf-certman library also implements a standard PKCS#11 interface to manage X.509 certificates. This allows usage of the Certificate Manager subsystem for applications that can’t be changed in order to use the libmssf-certman interface directly.

= External Documentation =

== MeeGo 2010 Conference ==

* [http://conference2010.meego.com/session/meego-security-what-it-and-why-do-we-care MeeGo Security: What is it and why do we care?]
* [http://conference2010.meego.com/session/mobile-simplified-security-framework-overview Mobile Simplified Security Framework Overview]
* [http://conference2010.meego.com/session/cost-security-developers-view The Cost Of Security, A Developer's View]

== Publications ==

* Mobile Simplified Security Framework, Linux Symposium paper, [[File:MSSF_OLS2010.pdf]]
* Mobile Simplified Security Framework, Linux Symposium slides, [[File:MSSF_Slides_OLS2010.pdf]]

Security

2011-02-02T18:07:23Z

Ryanware: /* MeeGo Security Bug Policy */

This page is a placeholder for the MeeGo Security related info

__TOC__

Other portions of MeeGo Security shall be here soon.

= MeeGo Security Architecture =

The [[Security/Architecture|MeeGo Security Architecture]] is documented here in the wiki.

= MeeGo Security Bug Policy =

* All MeeGo security defects are private to the Security_Group by default in addition to the submitter and the CC list.
** This is standard practice for Linux distributions and other operating systems
** The reason for this is that information in security bugs can be used as a road map to exploit MeeGo systems.
* To request addition to the Security_Group, please send mail to [mailto:security@meego.com?Subject=MeeGo%20Security%20Bug%20Access%20Request security@meego.com] explaining your need.
** People who want addition to this group will need to ''demonstrate'' that they need generic access to security bugs, not just access to specific security bugs.
*** People who need access to specific security bugs can request access to get added to the CC list.
* The list of members in the Security_Group will be audited by the MeeGo Security Lead every quarter.
* Once a security defect is resolved (by making a patch available or marking the bug as closed), it will also be made public by removing the Security_Group restrictions.

Security

2011-02-02T17:53:38Z

Ryanware:

This page is a placeholder for the MeeGo Security related info

__TOC__

Other portions of MeeGo Security shall be here soon.

= MeeGo Security Architecture =

The [[Security/Architecture|MeeGo Security Architecture]] is documented here in the wiki.

= MeeGo Security Bug Policy =

* All MeeGo security defects are private to the Security_Group by default in addition to the submitter and the cc list.
** This is standard practice for Linux distributions and other operating systems
** The reason for this is that information in security bugs can be used as a road map to exploit MeeGo systems.
* To request addition to the Security_Group, please send mail to security@meego.com explaining your need.
** People who want addition to this group will need to ''demonstrate'' that they need generic access to security bugs, not just access to specific security bugs.
*** People who need access to specific security bugs can request access they be added to the cc list.
* The list of members in the Security_Group will be audited by the MeeGo Security Lead every quarter.
* Once a security defect is resolved (by making a patch available or marking the bug as closed), it will also be made public by removing the Security_Group restrictions.

Security/architecture

2011-02-02T17:16:07Z

Ryanware: Redirected page to Security/Architecture

#REDIRECT [[Security/Architecture]]

Security

2011-02-02T00:50:37Z

Ryanware:

Security/Architecture

2011-02-02T00:50:03Z

Ryanware: /* Certificate Manager */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

{| class="wikitable" style="text-align: center" border="1"
|+ Simple Device Policy Example
|-
! scope="col" | SW Source Name
! scope="col" | Trust Level
! scope="col" | Public Key Info
! scope="col" | Possible Credentials
|-
| MeeGo.com || 100 || <code>ABCDEF...</code> || Cellular, UserData
|-
| Developer.org || 20 || <code>ACDEFC...</code> || UserData
|-
| Unknown || 10 || <code>---------</code> || UserData
|}

=== Certificate Manager ===

The MSSF Certificate Manager subsystem provides means of managing and securely storing the system’s X.509 signing certificates, user’s own certificates and the related private keys. These certificates can be used by various applications in MeeGo (like browser, e-mail and other applications) in order to perform authentication of the remote party or, in case of user’s certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manager subsystem is a libmssf-certman library, which provides a user space interface for MeeGo applications in order to perform actions described above.

When authenticating a remote service (for example, web site or mail server), an application usually needs to be able to verify an X.509 signing certificate, presented by this service. In order to do it, it needs to verify an authority, which signed this certificate. This, in turn, can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate. However, such a chain of certificates can’t be endless and therefore some certificates in this chain are usually self-signed certificates (also called root certificates), which are initially imported to the system and trusted by it. So, in order to verify a remote service’s certificate, an application needs to retrieve a set of system’s self-signed root X.509 certificates and verify the presented certificate against this set via some certificate chain. This use case is shown in Figure 6. A browser application received an X.509 certificate and needs to validate it. In order to do it, it uses the libmssf-certman interface:

[[Image:MSSF_Certman_Interaction_Cert_Retrieval.png|350 px|Certificate Manager high-level interaction view (Certificate retrieval)]]

# To ask the libmssf-certman for the set of the system’s self-signed certificates
# Libmssf-certman requests libmssf-crypt to verify the integrity of the certificate store
# The system’s cryptographic services verify the integrity
# If there is no compromise, libmssf-certman is notified
# The set of certificates is returned to the browser

Another typical use case for the libmssf-certman usage is handling of a user’s private keys that can be used to authenticate a user and user’s data to a remote service. This use case is shown in Figure 7. An e-mail application would like to sign a user’s email and therefore needs the user’s private key which is stored in the certificate manager.

[[Image:MSSF_Certman_Interaction_Privkey_Retrieval.png|350 px|Certificate Manager high-level interaction view (Private Key Retrieval)]]

# It requests the private key via libmssf-certman
# Which checks the protection method for the requested private key
# If the key is protected with a user passphrase, libmssf-certman requests it from the e-mail application
# The e-mail application requests the passphrase from the user
# The passphrase is passed to libmssf-certman by the e-mail application
# Which decrypts the private key and returns it to the e-mail application

The libmssf-certman library also implements a standard PKCS#11 interface to manage X.509 certificates. This allows usage of the Certificate Manager subsystem for applications that can’t be changed in order to use the libmssf-certman interface directly.

= External Documentation =

== MeeGo 2010 Conference ==

* [http://conference2010.meego.com/session/meego-security-what-it-and-why-do-we-care MeeGo Security: What is it and why do we care?]
* [http://conference2010.meego.com/session/mobile-simplified-security-framework-overview Mobile Simplified Security Framework Overview]
* [http://conference2010.meego.com/session/cost-security-developers-view The Cost Of Security, A Developer's View]

== Publications ==

* Mobile Simplified Security Framework, Linux Symposium paper, [[File:MSSF_OLS2010.pdf]]
* Mobile Simplified Security Framework, Linux Symposium slides, [[File:MSSF_Slides_OLS2010.pdf]]

Security/Architecture

2011-02-02T00:41:16Z

Ryanware: /* Certificate Manager */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

{| class="wikitable" style="text-align: center" border="1"
|+ Simple Device Policy Example
|-
! scope="col" | SW Source Name
! scope="col" | Trust Level
! scope="col" | Public Key Info
! scope="col" | Possible Credentials
|-
| MeeGo.com || 100 || <code>ABCDEF...</code> || Cellular, UserData
|-
| Developer.org || 20 || <code>ACDEFC...</code> || UserData
|-
| Unknown || 10 || <code>---------</code> || UserData
|}

=== Certificate Manager ===

The MSSF Certificate Manager subsystem provides means of managing and securely storing the system’s X.509 signing certificates, user’s own certificates and the related private keys. These certificates can be used by various applications in MeeGo (like browser, e-mail and other applications) in order to perform authentication of the remote party or, in case of user’s certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manager subsystem is a libmssf-certman library, which provides a user space interface for MeeGo applications in order to perform actions described above.

When authenticating a remote service (for example, web site or mail server), an application usually needs to be able to verify an X.509 signing certificate, presented by this service. In order to do it, it needs to verify an authority, which signed this certificate. This, in turn, can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate. However, such a chain of certificates can’t be endless and therefore some certificates in this chain are usually self-signed certificates (also called root certificates), which are initially imported to the system and trusted by it. So, in order to verify a remote service’s certificate, an application needs to retrieve a set of system’s self-signed root X.509 certificates and verify the presented certificate against this set via some certificate chain. This use case is shown in Figure 6. A browser application received an X.509 certificate and needs to validate it. In order to do it, it uses the libmssf-certman interface:

[[Image:MSSF_Certman_Interaction_Cert_Retrieval.png|350 px|Certificate Manager high-level interaction view (Certificate retrieval)]]

# To ask the libmssf-certman for the set of the system’s self-signed certificates
# Libmssf-certman requests libmssf-crypt to verify the integrity of the certificate store
# The system’s cryptographic services verify the integrity
# If there is no compromise, libmssf-certman is notified
# The set of certificates is returned to the browser

Another typical use case for the libmssf-certman usage is handling of a user’s private keys that can be used to authenticate a user and user’s data to a remote service. This use case is shown in Figure 7. An e-mail application would like to sign a user’s email and therefore needs the user’s private key which is stored in the certificate manager.

[[Image:MSSF_Certman_Interaction_Privkey_Retrieval.png|350 px|Certificate Manager high-level interaction view (Private Key Retrieval)]]

# It requests the private key via libmssf-certman
# Which checks the protection method for the requested private key
# If the key is protected with a user passphrase, libmssf-certman requests it from the e-mail application
# The e-mail application requests the passphrase from the user
# The passphrase is passed to libmssf-certman by the e-mail application
# Which decrypts the private key and returns it to the e-mail application

The libmssf-certman library also implements a standard PKCS#11 interface to manage X.509 certificates. This allows usage of the Certificate Manager subsystem for applications that can’t be changed in order to use the libmssf-certman interface directly.

File:MSSF Certman Interaction Privkey Retrieval.png

2011-02-02T00:39:24Z

Ryanware:

Security/Architecture

2011-02-02T00:38:31Z

Ryanware: /* Certificate Manager */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

{| class="wikitable" style="text-align: center" border="1"
|+ Simple Device Policy Example
|-
! scope="col" | SW Source Name
! scope="col" | Trust Level
! scope="col" | Public Key Info
! scope="col" | Possible Credentials
|-
| MeeGo.com || 100 || <code>ABCDEF...</code> || Cellular, UserData
|-
| Developer.org || 20 || <code>ACDEFC...</code> || UserData
|-
| Unknown || 10 || <code>---------</code> || UserData
|}

=== Certificate Manager ===

The MSSF Certificate Manager subsystem provides means of managing and securely storing the system’s X.509 signing certificates, user’s own certificates and the related private keys. These certificates can be used by various applications in MeeGo (like browser, e-mail and other applications) in order to perform authentication of the remote party or, in case of user’s certificates and related private keys, authenticate a user towards some remote service. The main component of the Certificate Manager subsystem is a libmssf-certman library, which provides a user space interface for MeeGo applications in order to perform actions described above.

When authenticating a remote service (for example, web site or mail server), an application usually needs to be able to verify an X.509 signing certificate, presented by this service. In order to do it, it needs to verify an authority, which signed this certificate. This, in turn, can be done by verifying the certificate signature against some known public key, which is stored inside another X.509 certificate. However, such a chain of certificates can’t be endless and therefore some certificates in this chain are usually self-signed certificates (also called root certificates), which are initially imported to the system and trusted by it. So, in order to verify a remote service’s certificate, an application needs to retrieve a set of system’s self-signed root X.509 certificates and verify the presented certificate against this set via some certificate chain. This use case is shown in Figure 6. A browser application received an X.509 certificate and needs to validate it. In order to do it, it uses the libmssf-certman interface:

[[Image:MSSF_Certman_Interaction_Cert_Retrieval.png|350 px|Certificate Manager high-level interaction view (Certificate retrieval)]]

# To ask the libmssf-certman for the set of the system’s self-signed certificates
# Libmssf-certman requests libmssf-crypt to verify the integrity of the certificate store
# The system’s cryptographic services verify the integrity
# If there is no compromise, libmssf-certman is notified
# The set of certificates is returned to the browser

Another typical use case for the libmssf-certman usage is handling of a user’s private keys that can be used to authenticate a user and user’s data to a remote service. This use case is shown in Figure 7. An e-mail application would like to sign a user’s email and therefore needs the user’s private key which is stored in the certificate manager.

File:MSSF Certman Interaction Cert Retrieval.png

2011-02-02T00:36:18Z

Ryanware:

Security/Architecture

2011-02-02T00:27:54Z

Ryanware: /* Device Security Policy */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

{| class="wikitable" style="text-align: center" border="1"
|+ Simple Device Policy Example
|-
! scope="col" | SW Source Name
! scope="col" | Trust Level
! scope="col" | Public Key Info
! scope="col" | Possible Credentials
|-
| MeeGo.com || 100 || <code>ABCDEF...</code> || Cellular, UserData
|-
| Developer.org || 20 || <code>ACDEFC...</code> || UserData
|-
| Unknown || 10 || <code>---------</code> || UserData
|}

=== Certificate Manager ===

Security/Architecture

2011-02-02T00:24:13Z

Ryanware: /* Device Security Policy */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===

The Device Security Policy defines the mapping between the software sources and the list of credentials that each software source can grant. A manufacturer, operator or even a device user can either define the device security policy when a platform is in “Developer Mode”. The software source is assumed to have some level of quality assurance and that the repository owner follows that process or ensures the process is followed by external, 3rd parties creating software for the repository.

MSSF can enforce different policies, starting from the strictest ones and ending all the way with a completely open developer platform. The owner of a device defines a device policy based on his needs and goals. Such flexibility allows a range of mobile devices targeted for different purposes and environments to use the same security framework. For example, an operator may want a device to give access to telephony functionality only to applications that originate from their own software repository. However, the user of a device in developer mode may want their own applications to have access to telephony. The flexibility of the device security policy allows different access to the same application in devices with different security goals without additional changes to the application itself. Additionally, updates to the device security policy allow fast reaction as the threat landscape for MeeGo platforms change over time. For example, while the risk of malware for MeeGo is currently relatively small, the security policy can be tightened down if in the future this circumstance changes.

Each software source can be represented by a single entry in a device policy file: software source name, trust level, key, and list of allowed credentials. For example, Table 2 shows a simple Device Security Policy which has two software sources defined: MeeGo.com and Developer.org. Both the “Cellular” and “UserData” credentials can be assigned to software, requesting them from MeeGo.com. However, only “UserData” can be accessed by software from Developer.org. Additionally, this generous device policy allows unknown software to access user data.

=== Certificate Manager ===

Security/Architecture

2011-02-02T00:23:24Z

Ryanware: /* Secure Software Distribution */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===

The process of software distribution is directly linked to the security architecture. It creates a trusted link between developers and end user devices by ensuring that software originated from any of a number of authenticated SW sources. This section provides a brief introduction to the main software distribution concepts.

MeeGo applications may come to the Package Manager from different software sources that can be either known or unknown. The notion of a “software source” is abstract and can represent a different range of entities starting from software repositories and ending with a single developer who can publish signed software packages on his web page. The Package Manager has access to a list of known software sources and their public keys. Each software source has a trust level associated with it. The trust level defines the software update rules for any package in the platform. Installed packages can be updated only from the same source they originally came from, or from a software source with a higher trust level. This rule ensures that trusted software couldn’t be updated with software from a less trusted repository. This applies even if the less trusted repository contains newer versions of software. In addition to this list of software repositories, the Package Manager maintains an additional software source called “Unknown”. All applications that can’t be considered to come from any of the known software sources would be considered to come from “Unknown”. The information about a software source is preserved through the application lifetime.

Each MeeGo software source is supposed to check its applications for robustness and security compliance against their own security policies. There are many different ways a software vendor can accomplish this, and that effort specifically falls outside the scope of this document.

=== Device Security Policy ===
=== Certificate Manager ===

Security/Architecture

2011-02-02T00:21:31Z

Ryanware: /* Cryptographic Services */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===

The MSSF Cryptographic Services subsystem provides an additional way to ensure the integrity and confidentiality of application data during run-time and between platform restarts. Cryptographic Services utilities are provided for the following TEE Services subsystem interfaces:

* Local cryptographic services
* Key management

The access to protected data can be accomplished:

* By the application specific key derived from the application identifier (AppID) and RDSK key
* Or by the shared key derived from the resource token name and RDSK key.

Figure 5 provides a high-level view of the typical interaction scenario when an application wants to protect the integrity of its data.

[[Image:MSSF_Crypto_Services_Interaction.png|350 px|Cryptographic Services Interaction View]]

# Application calls the libmssf-crypto library API to compute a local message authentication code (MAC) over the data.
# The libmssf-crypto library transfers this request to the security driver through a libtee provided interface.
# The security driver verifies if the application possesses the necessary credential.
# If so, the MAC is computed…
# …and returned to the application by passing through the security driver, libtee, and finally libmssf-crypto.

Once this is in place, the application can verify its own data at any time and can determine its own security policy if the integrity checks fail.

=== Secure Software Distribution ===
=== Device Security Policy ===
=== Certificate Manager ===

File:MSSF Crypto Services Interaction.png

2011-02-02T00:19:39Z

Ryanware: MSSF Cryptographic Services Interaction View

MSSF Cryptographic Services Interaction View

Security/Architecture

2011-02-02T00:13:56Z

Ryanware: /* Integrity Protection */

This page includes all references to MeeGo Security Architecture content.

__TOC__

= MeeGo Security Architecture =

This architecture is the result of the work of many different people. Thanks go to Elena Reshetova, Janne Karhunen, Casey Schaufler and Ryan Ware.

== For The Reader ==

The following document contains the overview description of Mobile Simplified Security Framework (MSSF) for the MeeGo.com release. MSSF is the basis of the MeeGo Security Architecture and will be delivered with MeeGo starting with the 1.2 release.

== Abstract ==

The purpose of the Mobile Simplified Security Framework (MSSF), in the MeeGo platform, is to protect the owner of a MeeGo-powered platform from getting their personal data and passwords stolen and used for malicious purposes, to prevent malware from misusing the device, to prevent the user from accidentally breaking the device software, and to make the platform meet the needs of software that requires a safe execution environment. This is accomplished by:

* A fine-grained, configurable, access control framework that can restrict the set of allowed operations according to the source and identify of an application.
* An extensive integrity checking system that ensures the authenticity of all executable files, as well as other important configuration files.
* Protection of sensitive data by means of encryption and signing, including enabling the use of a key derived from a hardware-protected, device-specific secret.

The main design goal is to accomplish all this without significant penalty in terms of performance and usability by using established open standards and having all implementation open-sourced. The other goal is to introduce only minimum changes to the standard Linux programming environment to make it easy for new programmers to start working with MeeGo.

== Security Goals ==

The main security goals are:

* '''Protect the user''' - Malicious applications may try to compromise users’ privacy by publishing the content of their phonebook or private messages to the Internet. They may also try to incur costs to users by calling expensive, premium numbers or using the GPRS data connection extensively while roaming.
* '''Protect the device''' - Malicious applications may try to change some device parameters that may cause the device to malfunction or, in the worst case, even lead to the device becoming completely unusable. For example, changing the battery charging levels may lead to malfunction. Also, malicious applications should not be able to change the device parameters in a way that would violate regulations or the setup of the mobile operator.
* '''Protect the business''' - Some MeeGo devices are sold through the operator channels, which may require support for SIM lock functionality. A malicious user or application should not be able to disable such a lock. Also, MeeGo device distribution channels may require installation or blocking of certain applications or services without the possibility of users or applications changing these settings.
* '''Enable new services''' - Services like mobile payments and copyright protection require strong security support from the operating system. The security of these services is essential for their use, so MeeGo provides such enablers.

== MSSF Evolution ==

Currently, there are two major versions of MSSF: version 1 and version 2. MSSF version 1 is the security framework that Nokia delivered as a part of earlier products. MSSF version 2 is an evolution of that framework which is included in MeeGo 1.2. The source code for MSSFv2 is found [http://meego.gitorious.org/meego-platform-security here]. The differences between version 1 and version 2 are the main focus of this document and they are primarily in the areas of: access control, integrity protection, and secure software distribution.

There are several reasons for updating MSSF to version 2, which can be shortly described as:

* New Features – Version 1 lacked a number of important features in the area of access control, such as mandatory run-time filesystem access controls and socket access control.
* Upstream Sources – There is a requirement that all MeeGo components must be upstream and therefore all version 1 kernel modules and patches would need to be accepted by the upstream Linux kernel. However, upstreaming to the Linux kernel of these components was identified as being extremely difficult as it already included stable components that had comparable functionality. Unfortunately, the upstream modules (specifically SMACK* and IMA/EVM) do not provide all the functionality needed by MeeGo. So, the decision was made to contribute to these open-source projects to get the required enablers into the Linux kernel.

== Security Framework Components ==

The MSSF has these components, which are implemented by various platform subsystems.

* Trusted Execution Environment (TEE) Services – Provides secure cryptographic services and key management for other MSSF subsystems.
* Integrity Protection – Ensures protection of the filesystem.
* Access Control – Limits application access to protected resources.
* Cryptographic Services – Provides data integrity and confidentially protection for applications.
* Secure Software Distribution – MeeGo relies on the secure software distribution model, which ensures the authentication of software packages and allows the remote management of security policies.
* Certificate Manager – Provides interfaces to store and manage the platform’s X.509 signing certificates, the user’s own certificates, and any related private keys.

All of these portions of the software stack are influenced by the Device Security Policy, which allows the OEM or operator to configure the security policies for the device.

[[Image:MeeGo_Security_Framework.png|MeeGo Security Framework]]

=== Trusted Execution Environment ===

The MSSF framework enables hardware security components, if they are available. These components are then abstracted by the Trusted Execution Environment (TEE) Services subsystem of MSSF. The expectations from hardware security components are similar to those of a Trusted Platform Module ([http://www.trustedcomputinggroup.org/developers/trusted_platform_module TPM]) or Mobile Trusted module ([http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification MTM]) specifications.

The TEE Services subsystem provides interfaces to tamper resistant services implemented inside security hardware. The actual implementation of these services depends on the security hardware itself and may vary considerably. However, MSSF poses minimal requirements towards the security hardware, which are described below:

* '''Securely Provisioned Root Public Key (RPK)''' - The root public key is a one-time programmable (OTP) key, which can be used as a root key for identifying the SW stack of the device.
* '''Securely Provisioned Root Device Specific Key (RDSK)''' - The root device specific key is a symmetric OTP key, which can be used as a root key for local cryptographic operations to guarantee data integrity and confidentiality. It can also be used to derive a unique identifier for the device, if needed.
* '''Trusted Execution Environment''' - The hardware must provide an environment where cryptographic operations and key management take place in an isolated environment.

These requirements provide a basis for building MSSF services on top of security hardware. If these requirements cannot be satisfied or the target platform does not have a security hardware subsystem, the level of security provided by MSSF decreases significantly. Operations that would take place within hardware instead take place in software, which results in a reduced bar of protection. While not optimal, this reduced bar still provides better protection than generic Linux protections.

==== Boot Process ====

This document does not go into specific secure boot implementations. MeeGo is expected to work with various hardware solutions and implementations and there are a wide variety of ways to perform a secure, measured platform boot. The MeeGo Security Framework assumes that a secure boot solution enables a secure boot to the MeeGo kernel. This ties the platform root-of-trust to the kernel. From here, the kernel can then extend the root-of-trust to other portions of the software stack. If a secure boot solution is not provided for the platform, the level of security provided to the platform decreases significantly.

=== Access Control ===

The purpose of the MeeGo Access Control subsystem is to limit the access to the operating system resources by enforcing the “principle of least privilege”. To be able to explain this principle and its applicability to MSSF ACS, let’s introduce a number of classic concepts.

==== Classic Access Control Concepts ====

The most common abstraction for representing a computer system is dividing it into ''subjects'' and ''objects''.

A ''Subject'' is an active entity, which represents a system’s user or process in the computer system. The MeeGo access control subsystem uses processes as the granularity of control, meaning that the access control in MeeGo is process based.

An ''Object'', also known as a ''resource'', is a passive entity, which represents a file, system resource, or even potentially a subject. The last means that an executable file is an object of a computer system, but when it starts to execute, it becomes a subject of this system.

The third commonly use abstraction is an ''Access Type''. It is an operation which a subject can perform on an object. The concrete meaning of access type depends on the commuter system. For the file server, it can be an ability to read an object, to write to it, or to execute it. For database systems, access types can be an ability to insert a new record in a table, to search for data in database, and so on.

==== UNIX Access Control ====

After defining the goal of our access control model, let’s discuss the reasons why the current classic UNIX access control isn’t enough to achieve this goal. UNIX access controls were originally developed as “user-centric” access controls. The goal of such ACs is to separate the users and their access to each other’s data. The model of adversary for the classic UNIX model is a malicious user that tries to obtain another user’s data. However, currently most MeeGo devices are considered to be single-user devices. The model of an adversary is mainly malicious software that can be installed by a user and may cause undesirable consequences.

The changed environment and the new adversary model require a change to the access control model. However, it is important to mention that there were a number of attempts to extend the classical UNIX AC model. These include projects such as POSIX* capabilities. Unfortunately, current Linux distributions all support the use of a ‘root’ user. Moreover, the limited amount of defined POSIX capabilities led to the fact that some of them began to be used to protect quite different functionality than intended. For example, the CAP_SYS_ADMIN capability protects a wide range of system objects. This reduces the effect of capabilities separation and leads to diminishing the principle of least privilege. Additionally, POSIX capabilities were introduced to protect specific Linux interfaces and functionality. It remains difficult to use these capabilities to map to items that concern ordinary users.

==== MeeGo Access Control Concepts ====

As was explained in the previous section, the standard Linux ACs can’t be used to fulfill the main goals of MeeGo access control. To resolve this, the following AC concepts were introduced.

A resource is a virtual object, which represents some functionality. It can be a file on the filesystem, a D-Bus service, and so on. Some systems’ resources are considered sensitive because they provide access to some critical functionality or data. To access sensitive resources, an application may be required to possess a specific credential. The standard Linux access control has the following credentials, which can be associated with the process: user identifier (UID), group identifier (GID), POSIX capabilities, and supplementary groups. The MeeGo AC framework introduces two new types of credentials: ''Resource Token'' and ''Application Identifier''.

A ''resource token'' is a string that is understandable for both users and developers. Examples of resource tokens are “Location” and “Cellular”. As an example, let’s consider the “Cellular” resource token. It represents access to cellular functionality on a device (GSM* call, SMS and GPRS data). The real system objects that will be protected by this resource are D-Bus interfaces for csd-call, csd-sms, csd-gprs, and higher-level D-Bus interfaces. The initial set of protected resources will be defined based on the risk analysis for a MeeGo platform. Each application has a possibility to define new resource tokens, which the application itself provides and may want to use to protect its sensitive resources.

For an application to request or provide a resource token, it needs to have a manifest file inside of the package. In this file, an application declares the credentials, which it needs to work properly, and the credentials that are provided by the application.

The second type of credential is the ''application identifier'', which should fulfill the following requirements:

* It should be impossible to forge.
* It should uniquely identify an application through its entire life cycle.
* It should remain the same for the application, regardless of application restart, application updates, multiple application instances, or platform reboots.

Such an identifier in our system, allowing reliable identification of an application through its entire life cycle, is generated by the package manager and represented by a triplet:
<blockquote>''AppID'' = {''SourceID'', ''PackageName'', ''ApplicationSpecificName''}</blockquote>

The ''SourceID'' is a unique identifier of a software source. It should be tied with a key that is used by this software source, but it should not directly depend on the key since the key may be updated over time. The ''PackageName'' is a package name without a version number. ''ApplicationSpecificName'' is defined by a developer and is provided for the case where a developer has a number of different binaries within their package that require different access rights. It is defined inside the Manifest File. In the case where no such definition exists within the manifest, the ''ApplicationSpecificName'' shall be assumed to be ‘None’.

As an example, let’s use ''AppID'' = “com.meego.cool-tools.addressbookplugin”. In this case, “com.meego” is the ''SourceID'', “cool-tools” is the ''PackageName'', and “addressbookplugin” is the ''ApplicationSpecificName''.

In version 1 of MSSF, resource tokens and application identifiers were implemented by a number of specialized kernel modules. However, because of reasons previously mentioned, the decision was made to change the access control subsystem implementation to use one of the mainline Linux Security Modules, Simple Mandatory Access Control Kernel (SMACK)*.

==== SMACK AC Module Overview ====

SMACK is a mainline Linux Security Module (LSM) which provides a complete mandatory access control model. SMACK has a notion of ''label'' which identifies a security characteristic of subject or object. The default rule is that a subject can only access an object if their labels match. SMACK access rules are defined by triplets:

<blockquote>{''Subject'', ''Object'', ''Access''}</blockquote>

Here, ''Access'' refers to the access type term, defined in Classical Access Control concepts. SMACK also has a number of default system labels that follow a set of default rules.

A detailed description of SMACK can be found in the [http://schaufler-ca.com/data/SmackWhitePaper.pdf SMACK White Paper]. However, a brief overview is given here to introduce relevant concepts. While we have previously discussed the ideas of ''subject'', ''object'' and ''access'', we have not previously discussed the term ''label''. In terms of SMACK, a label is data that identifies the Mandatory Access Control (MAC) characteristics of a subject or object. SMACK labels are between 1 and 23 ASCII characters in length. All single character labels using special characters are reserved by SMACK. Of these, there are four default labels currently defined:

* ‘'''_'''’ – Defined as the “floor” tag.
* ‘'''^'''’ – Defined as the “hat” tag.
* ‘'''*'''’ – Defined as the “star” tag.
* ‘'''?'''’ – Defined as the “huh” tag.

These and other system-defined labels are attached to subjects and objects within the system in various ways. For example, a file (object) has a SMACK label attached to it as part of a filesystem extended attribute. A process (subject) has a SMACK label as part of the process structure.

The SMACK LSM will then use the default set of rules (interpreted in order) to process access controls, given the labels that have been applied to the system. The default rules are:

# Any access requested by a subject labeled ‘*’ is denied.
# A read or execute access request by a subject labeled ‘^’ is permitted.
# A read or execute access request on an object labeled ‘_’ is permitted.
# Any access requested on an object labeled ‘*’ is permitted.
# Any access requested by a subject on an object with the same label is permitted.
# Any access requested that is explicitly defined in the loaded rule set is permitted.
# Any other access is denied.

In the above list, rule 6 allows the SMACK access control list to be expanded and modified to fit the security goals and requirements for a particular platform. Below is a contrived example of user-defined SMACK rules that implement an information hierarchy for Unclassified, Classified, Secret, and Top Secret information.

{| class="wikitable" style="text-align: center" border="1"
|+ SMACK Access Controls for Unclassified, Classified, Secret and Top Secret
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| Classified || Unclassified || rx
|-
| Secret || Classified || rwx
|-
| Secret || Unclassified || rx
|-
| TopSecret || Secret || rx
|-
| TopSecret || Classified || rx
|-
| TopSecret || Unclassified || rx
|}

This allows a pseudo-hierarchy of access, such as defined by this diagram:

[[Image:Classification_hierarchy.png|500 px|Sample SMACK Hierarchy]]

==== SMACK Usage in MSSF ====

The SMACK LSM implements MSSF AC concepts this way:

* '''Application Identifier''' - An application identifier for an application is stored using the SMACK subject label.
* '''Resource Token''' - Resource tokens are represented as SMACK object labels.

A possession of resource tokens for applications is expressed through SMACK rules this way. Suppose we have an application that wants to obtain the location information and make GSM calls. It requests this functionality through the following manifest:

<blockquote><pre><mssf>
<request>
<credential name=”Location”/>
<credential name=”Cellular”/>
<for path=”/usr/bin/myapp” id=”myapp”/>
</request>
</mssf></pre></blockquote>

Assume the application comes from the MeeGo.com software repository and its package name is “my-app-pkg”. The generated application identifier would be “com.meego.my-app-pkg.myapp”. The possession of the requested resource tokens is recorded in the SMACK rule set by:

{| class="wikitable" style="text-align: center" border="1"
|+ Example SMACK Rule Set
|-
! scope="col" | Subject Label
! scope="col" | Object Label
! scope="col" | Access Type
|-
| com.meego.my-app-pkg.myapp || Cellular || rx
|-
| com.meego.my-app-pkg.myapp || Location || rx
|}

One note here: Although for clarity sake the SMACK subject labels above have been presented in such a way that the application ID itself is used for the subject label, in practice it will not be used this way. Because SMACK imposes a 24-byte length limitation on labels and application IDs can be arbitrarily long, a 32-bit unique identifier is generated from the application ID and stored as the subject label.

Figure 3 shows the basic components of MSSF AC and their interaction during application installation.

[[Image:MSSF_Installation_Components.png|350 px|Installation Components of MSSF Access Control Subsystem]]

# An application package, together with a manifest file, comes to the Package Manager.
# The Package Manager checks the Device Security Policy to determine the maximum set of credentials which can be granted for this application.
# The Package Manager generates the application identifier for the new application and sets the corresponding SMACK subject label in the <code>security.SMACK64EXEC</code> extended attribute.
# The Package Manager makes additions to the SMACK rules to mark the possession of certain resource tokens and their access type.
# If the package provides a D-Bus service that the application would like to protect using manifest rules, then the D-Bus configuration policy is also updated.
# The Package Manager sends the additions to the SMACK rule set stored in the kernel.

The enforcement of access controls during runtime happens in one of these ways:

* '''Kernel Enforcement''' - The Linux kernel already does access control related enforcement checks for the objects, protected with user identifiers (UIDs), group identifiers (GIDs), supplementary groups, and POSIX capabilities. The SMACK LSM kernel module performs additional access control checks for the system objects, protected with SMACK labels.
* '''D-Bus Daemon''' - The D-Bus daemon is modified to perform the credentials checking based on the modified D-Bus configuration policy.
* '''Application Enforcement''' - If necessary, each application can use the libcreds library to check the credentials (standard Linux and MSSF specific) of the client connected to it over D-Bus or local socket interfaces. This is needed if an application needs to enforce more fine-grained access control than per socket or D-Bus interfaces can manage.

==== Loading Shared Libraries ====

MSSF access control is done on the process level. However, it is quite typical for a process to load a shared library during its execution, to use some functionality it provides. This creates a possibility for a malicious library to get loaded to a process with a set of sensitive credentials and misuse these credentials. Moreover, the case of plug-in based architectures is very common on the MeeGo platform. These issues dictate the need to provide secure loading of shared libraries.

The rule chosen for MeeGo to enforce secure loading of libraries is that at the moment a shared library is loaded into a process, the process should not possess more credentials (UIDs, GIDs, supplementary groups, POSIX capabilities, and resource tokens) than the software source of the library is allowed to grant. In MSSF version 1, the Validator LSM module enforced this rule. For MSSF version 2, the long-term goal is to use an LSM composer. An LSM composer would allow combining the abilities from multiple LSMs into a single, cohesive entity. Unfortunately, a LSM composer will not be available in time for the MeeGo 1.2 release. The short-term solution for this is to add the additional functionality directly into the SMACK LSM using the mmap LSM hook to enforce the rule. Using this hook ensures that when an application tries to load a shared library, the kernel calls into the SMACK LSM, which can then determine the maximum credentials the process is allowed, given the library it is loading.

=== Integrity Protection ===

It is the responsibility of the MSSF Integrity Protection subsystem to verify the integrity of all user space components, data files, and anything else that resides in the filesystem.

The MSSF version 1 integrity protection subsystem was implemented with the help of the Validator kernel module and a number of user space components. However, the implementation of this subsystem changed significantly due to the mainline kernel already having its own integrity protection subsystem: Integrity Measurement Architecture ([http://linux-ima.sourceforge.net/#Integrity%20Measurement%20Architecture IMA]). One of the main benefits of the move to IMA is usage of extended attributes to store reference hashes of files, which allows removal of the need to keep reference hashes in kernel memory during system run-time. The reference cryptographic hash (currently SHA-1) for each file is stored in the security.ima extended attribute and the integrity of the file is verified every time the IMA kernel module accesses it. There is also a caching mechanism available to improve the performance by removing the need to verify the files that were not changed in run-time since the last IMA measurement. An additional difference between IMA and Validator is that IMA heavily relies on ACs for integrity protection during system run-time. In practice, this means that the security.ima extended attribute is recalculated every time the file is changed during system run-time and all levels of access control protection allowed the change.

The downside of using the security.ima extended attribute is that it contains a non-keyed hash resulting in a protection mechanism that gives no protection against offline modifications. Depending on the device, it could be very easy and straightforward for an attacker to remove the storage device and modify it in another system. To address this, IMA has an extension called the Extended Verification Module (EVM). The latest available white paper describing IMA and EVM is located [http://heanet.dl.sourceforge.net/project/linux-ima/linux-ima/Integrity_overview.pdf here]. EVM provides offline protection for filesystem metadata, including the extended attributes by calculating a keyed cryptographic hash (currently HMAC-SHA1) over them and storing this hash in the <code>security.evm</code> extended attribute. This HMAC calculation must be done by a trusted execution environment on the platform with a hardware protected key. Without this, the key used for the HMAC calculation must be stored somewhere in the filesystem and offers no additional protections over IMA alone. The protection of the key can be done by:

* '''Direct usage of TEE services and keys''' - In this case, EVM would use the interfaces provided by the TEE services subsystem to compute and verify the keyed cryptographic hash. The key for these operations would never be exposed outside of TEE and would provide the best level of protection. However, this alternative could present a large performance impact on the system, depending on the number of operations needed by the application and the underlying security hardware implementation.
* '''Key export from TEE upon kernel validation''' - This method is proposed by IMA/EVM authors. After successful kernel integrity verification during the boot sequence, the kernel is given a key that can be used by the EVM module to compute and verify the keyed cryptographic hashes. In this case, the performance impact could be relatively smaller because a HW security subsystem will not be invoked for each verification operation. However, the risk of key compromise is higher, since even a verified kernel will have a security defect that will be later discovered and made exploitable.

The choice between the above two approaches should be based on performance measurements for the specific platform security goals and requirements.

A simplified picture of the MSSF integrity protection subsystem and its component interactions can be viewed in Figure 4.

[[Image:MSSF_Integrity_Protection.png|350 px|MSSF Integrity Protection Subsystem]]

<blockquote>0. The software package comes to the package manager.</blockquote>
# The security.ima and security.evm (if applicable) extended attributes for all files provided by the package are set up.
# When a file is accessed…
# …the IMA module intercepts the system call and calculates the cryptographic hash over the contents…
# …and accesses the security.ima extended attribute to compare the calculated hash with the reference hash.
# This triggers the EVM module…
# …which performs verification of the security.ima extended attribute (among others) by using the value stored in the security.evm extended attribute.
# If verification succeeds, then IMA is given the security.ima attribute value. Otherwise, the IMA module receives an error.

=== Cryptographic Services ===
=== Secure Software Distribution ===
=== Device Security Policy ===
=== Certificate Manager ===

File:MSSF Integrity Protection.png

2011-02-02T00:08:31Z

Ryanware: MSSF Integrity Protection Subsystem

MSSF Integrity Protection Subsystem

Security/Architecture

2011-02-02T00:03:31Z

Ryanware: /* Loading Shared Libraries */

Security/Architecture

2011-02-02T00:02:51Z

Ryanware:

Security/Architecture

2011-02-01T23:56:10Z

Ryanware:

File:MSSF Installation Components.png

2011-02-01T23:48:39Z

Ryanware: Installation Components of MSSF Access Control Subsystem

Installation Components of MSSF Access Control Subsystem

File:Classification hierarchy.png

2011-02-01T23:37:36Z

Ryanware: Hypothetical SMACK label hierarchy

Hypothetical SMACK label hierarchy

Security/Architecture

2011-02-01T23:19:32Z

Ryanware: Created page with "This page includes all references to MeeGo Security Architecture content. __TOC__ = MeeGo Security Architecture = This architecture is the result of the work of many different…"

File:MeeGo Security Framework.png

2011-02-01T22:40:24Z

Ryanware: Diagram of the MeeGo Security Framework

Diagram of the MeeGo Security Framework

Architecture/Documentation/Security/

2011-02-01T21:44:18Z

Ryanware: moved Architecture/Documentation/Security/ to Architecture/Documentation/SSO Security/: SSO is at best a subcomponent of security for MeeGo. It is not security itself.

#REDIRECT [[Architecture/Documentation/SSO Security/]]

Architecture/Documentation/SSO Security/

2011-02-01T21:44:18Z

Ryanware: moved Architecture/Documentation/Security/ to Architecture/Documentation/SSO Security/: SSO is at best a subcomponent of security for MeeGo. It is not security itself.

[[Category:Accounts and SSO]]

<center>SingleSignOn Architecture</center>

<center>Subsystem Architecture Specification</center>

= Document control =
== References ==

{| class="prettytable"
| '''Tag'''
| '''Document name'''
| '''Repository (with hyperlinks)'''

|-
| <nowiki>[ArchGoals</nowiki>]
| Architecture Goals
| [xxx]

|-
| <nowiki>[SystemModel]</nowiki>
| Maemo System Model
| [xxx]

|-
| <nowiki>[PDBv2]</nowiki>
| Package database
| [xxx]

|}

== Glossary ==

{| class="prettytable"
| '''Acronym or term'''
| '''Description'''

|-
| API
| Application Programming Interface

|-
| SASL
| Simple Authentication and Security Layer

|-
|
|

|}
== Summary of changes in current version ==
Update of changed figures and descriptions.

= Architecture =

== Licensing and IPR view ==
signond component is licensed as GPLv2 due to dependencies. SSO client library is licensed as LGPLv2.1.

Authentication plugins are proprietary, except the built-in plaintext and SASL plugins. SASL plugin is based on open source component.

There are no suitable available open source solutions, which would match the requirements even closely.

== Configurability ==
Locations for database and plugins can be configured during compilation time.

== Packages ==

{| class="prettytable"
| '''Package'''
| '''ver'''
| '''doc'''
| '''dev'''
| '''dbg'''

|-
| libsignon-qt
| 0
| doc
| dev
| dbg

|-
| libsignon-glib
| 1
| doc
| dev
| dbg

|-
| signond
| 0
| doc
| dev
| dbg

|-
| signon-plugins
|
|
| dev
|

|-
| signon-passwordplugin
|
|
|
|

|-
| signon-saslplugin
|
|
| dev
|

|-
| signon-doc
|
|
|
|

|-
| signonui-informer-extension
|
|
|
|

|-
| libsignon-ui
| 0
| doc
| dev
| dbg

|-
| signon-ui
|
|
|
| dbg

|-
| keychain-ui
|
|
|
| dbg

|}
Table 3: Packages provided

= Performance =
== General Performance Considerations ==
* Plugin system provides flexibility to add features
* Data set is limited by user credentials
* Typically users have less than 100 accounts with credentials
* Some operations require remote server responses and time performance is not critical issue
* Long operations are asynchronous by default

== Memory ==

{| class="prettytable"
|  
| Explanation
| <nowiki>Size [kB]</nowiki>

|-
| Flash/OneNAND
| Program & library files
| 2048

|-
| Flash/eMMC
| Credential database
| 4096

|-
| RAM/Idle
| Signond daemon
| 850

|-
| RAM/Peak
| Signon-ui
| 3048

|}

== Runtime ==
* One daemon running
* In typical use case 2-6 DBUS messages are sent
* Token renewal is periodic, depending on service
* Started on demand
* Application start time not affected

== Power Consumption ==
Daemon is in sleep when applications do not need authentication. Power consumption is minimal.

= Security =
SignOn is huge security risk. It is storing user credentials which should be kept safe. This could also include credit card numbers etc.

- Features that require high (admin / root) permissions or are a part of trusted computing base (kernel, etc.)

- User data or personally identifiable information (PII) is handled

- Network connections are used or relied on

- Externally supplied data is being processed

- Financial transactions are processed or billable events are created

- Cryptographic functionality (algorithms, random number generators, protocols) are used or a 'security feature' is being implemented

* Operational environment of a component or expectations of its operation change

A table below is depicting executables and their credentials.

{| border="1" cellpadding="5" cellspacing="0"
|+'''Credentials required by Single Sign-On subsystem executables'''
|-
! style="background:#efefef; width:200px;" | Executable
! style="background:#efefef; width:350px;" | Credential
|-
| signond
| UID::root
|-
| signond
| GID::root
|-
| signond
| CAP::setuid
|-
| signond
| CAP::dac_override
|-
| signond
| CAP::sys_module
|-
| signond
| CAP::sys_admin
|-
| signond
| CAP::mknod
|-
| signond
| CAP::ipc_lock
|-
| signond
| *::sso-encryption-token
|-
| signonpluginprocess
| UID::signon
|-
| signonpluginprocess
| GID::signon
|}

= Open items =

{| class="prettytable"
| '''<nowiki>#</nowiki>'''
| '''Item'''
| '''Status'''
| '''Description'''

|-
| 1
| Locked device
| closed
| Should encrypted filesystem be closed when device is locked?

|-
| 2
| DBUS id
| closed
| How to obtain unique identifier of D-BUS peer. Officially not yet supported by Security Framework.

|-
| 3
| Lock code
| closed
| Device lock code setting/getting is not defined.

|-
| 4
|
|
|

|-
| 5
|
|
|

|}

Security Advisories

2011-02-01T21:33:30Z

Ryanware:

==MeeGo Security Advisories==

All MeeGo security advisories are now available here [http://meego.com/downloads/releases/security-advisories].

MeeGo Conference 2010

2010-09-23T18:57:47Z

Ryanware: /* General */

The information below is work-in-progress.

== About ==

''' [http://conference2010.meego.com/ MeeGo Conference] will be held at Aviva Stadium in Dublin, Ireland November 15-17th, 2010'''

The MeeGo Conference replaces the Maemo Summit. We're using the term "conference" because The Linux Foundation usually uses the term "summit" to refer to invitation-only events, and since the MeeGo conference is open to anyone who would like to attend, we decided to refer to it as the MeeGo Conference to avoid confusion.

Our Call for Proposals has begun! Would you like to speak at the first MeeGo Conference? Anyone who wants to speak at the conference must [http://conference2010.meego.com/news/call-session-proposals-has-started submit a proposal]!

Submit your proposals on a variety of topics including:
*Hardware support
*Platform development
*Application development
*MeeGo project, process and progress
*and any other MeeGo related topics

Call for proposals closes August 23rd and you will receive an email on whether or not your session is approved by September 24, 2010.

Registration is [http://conference2010.meego.com/ open now].

== Sponsors ==

Prospectus is now available, please send to anyone who is interested in sponsoring MeeGo Conference 2010! [http://wiki.meego.com/images/MeeGo_Prospectus_2010_%282%29.pdf MeeGo Conference Prospectus]

== Audience ==

The MeeGo Conference targets a technical audience of:
* MeeGo developers
* OSVs, OEMs, and other integrators
* Other MeeGo project contributors

'''Other target audience suggestions'''
* Relevant media representatives (bloggers, promoters)

== Format and Logistical Details ==

* There are tentative plans for some [[MeeGo_Conference_2010/Early_Bird_Events|early bird sessions]] organized by community members on the afternoon of Saturday, November 13 and Sunday, November 14.
* The main event is a 3 day event, begins Monday Nov. 15th thru Wednesday Nov. 17th
* The first two days (Monday and Tuesday) will have scheduled sessions, and Wednesday will be an [[MeeGo Conference 2010/Unconference|unconference day]].
* We currently have evening events planned on Monday Nov. 15th at the Stadium, Tuesday Nov. 16th at Guinness Storehouse and will have tickets to the Ireland / Norway football game on Wednesday Nov. 17th.
* Conference Held at Aviva stadium
* Conference Space that we have:
** Presidents Terrace for Keynotes Day 1 sits 1200 theatre style or 580 cab ([http://www.lmc.ac.uk/home/hiring/seating.php cabaret style]) - suggesting theatre style for the keynotes
** Breakout session will be used as follows:
*** Level 02
**** 1. Presidents area split in half area 1 sits 300 cab
**** 2. Presidents area 2 sits 280 cab
**** 3. Vavasour suite sits 80 cab
*** Level 03 (where you enter)
**** The Atrium- registration/welcome/tea and coffee breaks
**** The flow between the Atrium and the next break out area called the Henry suite will be an area for a proposed Technology Showcase for MeeGo projects to be displayed and demo's.
**** 4. 1872 area sits 120 cab is the 4th breakout area opposite the atrium on the other side of the stadium.
*** Level 04 (stairs/elevator from the atrium)
**** 5. Havelock suite sits 130 cab- 5th breakout area
**** 6. Media center- in another part of the stadium: Perfect for a Graphics track or UI track based on the space.
* Hotels being used are the D4 hotels and you may book through registration site (read about details on site below)
* Registration site is planned to go up no later than August 7. but we are aiming for it to be up mid-July.
* The Registration will have a place for submissions to the call for papers (including submissions from Intel / Nokia) and a small selection committee will be responsible for choosing the presentations based on the merits of each submission.
* Anyone is welcome to submit a proposal or attend the event.
* The event will be free for attendees
* Sponsorship Prospectus is attached under Sponsor section, please send to anyone interested
* Updated 6/22/10 AL

== Location ==

Aviva Stadium in Dublin, Ireland- November 15-17th, 2010

Contract is in place and planning information will be updated online for your involvement:)

* [http://www.avivastadiumevents.ie/stadium.aspx Aviva Stadium]
* Conference facility has held for us one plenary room for the keynote session, and 6-8 breakout rooms to seat 100, I will be creating a presentation to place online, so everyone will see where and what rooms we will be the seesions of the conference in.
* Dublin is an easy city to get to for international travelers
* Venue is right on mass transit line (DART)
* Outside of Schengen area, non-EU citizens would require visa [http://www.dfa.ie/home/index.aspx?id=8777 Visa information for Ireland]

== Accommodation ==

* We have reserved a block of 530 rooms with D4 Hotels, in three hotels near the location. Rooms bookings are available [http://conference2010.meego.com/logistics/hotels through the conference site]. We will also have a 24hr networking room in the hotels during the conference
* Sponsored accommodation will be in this venue only - see [[#Sponsored_participants | sponsored participants]] for more information on requesting sponsorship. In the event of cancellation, the intial deposit on reservation will not be refunded
* Rooms are available from €65 per night to €115 per night through the conference registration system
* We are also holding 100 rooms at the Herbert Park hotel again only a couple blocks from the stadium

== Video coverage ==
This is the plan so far:

* There is a professional team dedicated to record, stream, edit and upload all the videos.
* All the tracks of the first two days will be recorded. The videos will be uploaded on the same evening or up to 48 hours later. The limitations are the editing work and also the risk of overloading the network bandwidth during the conference hours.
* In addition to this, the main room will have live streaming for all sessions during the first two days.
* The plan for the unconference day still needs to be defined but in any case the same video crew and equipment will be available.

Volunteering: is someone is interested in shooting additional video coverage please share your ideas at the meego-community mailing list.

== Sponsored participants ==
The organization has a budget to sponsor the travel and accommodation of selected community contributors. Participants willing to be sponsored must request it through the conference registration. The requests will be evaluated by the Sponsoring Committee (see below).

The idea is to handle the approvals through several rounds of acceptance: first the speakers approved, then the requesters obtaining unanimous support, then the rest until all the sponsorship budget is allocated. An private online spreadsheet will be used to register the votes of the committee members. The discussion will be held through mail and we will organize IRC or conference meetings if needed. The rough prioritisation used by the committee shall be:

# Speakers.
# Organisers/conference logistical people who aren't being paid to.
# Active MeeGo community members:
## Developers (both of MeeGo, and MeeGo applications)
## Bug reporters
## Community office-type stuff
## Anyone else making a valuable contribution
# Active legacy community members:
#* Maemo community members (karma ''helps'' here, but isn't a be-all and end-all)
#* Moblin community members
# Members of core upstream projects

Each request shall, of course, be made on a case-by-case basis.

If you have requested sponsorship and you require a 'complicated' visa please contact Quim Gil explaining your case and adding a URL to your meego.com profile.

If you have applied for sponsorship and you can only attend the conference if being sponsored, then don't book anything until you have got a confirmation. The first round of sponsorship confirmations will be sent out on 24th September.

The way the Linux Foundation handles this process in their conferences is simple: you find the best trip, get approval from Angela Brown (Linux Foundation), book your trip and the LF will reimburse you. If you have been approved and you don't have anybody around you with a credit card to do the booking then contact Angela and explain your case. This is no guarantee for anything but she is the one that will be coordinating these reimbursements.

The hotel reservation of sponsored participants will be booked by the Linux Foundation directly.

TO BE DEFINED: We are still discussing whether 1/2 extra nights can be sponsored for the sponsored contributors involved in the [[MeeGo_Conference_2010/Early_Bird_Events|Early Bird Events]] during the previous weekend. The first step is to confirm that those events will happen.

=== Time line ===
* Sep 20: Infra setup. Fine tuning details. Sponsorship approval of accepted speakers starts.
* Sep 24: Checkbox to request sponsorship removed from registration. No new sponsorship requests accepted.
* Sep 24: First wave of sponsorship requests approved: accepted speakers.
* Sep 28: Each sponsorship committee member has gone through all the candidates voting Yes/No in the private spreadsheet.
* Oct 1: Second wave completed: candidates with 5/5 votes.
* Oct 8: Third wave completed: candidates with 4-3 votes, depending on budget available.
* Oct 15: Resolution on remaining cases. All requests are accepted/declined at this point.

== Team ==
* Coordination: [http://meego.com/users/dawnfoster Dawn Foster] and [http://meego.com/users/qgil Quim Gil].
* Logistics: [http://meego.com/users/amyleeland Amy Leeland] coordinates. Specific areas and people in charge to be listed below.
** Specific areas go here.
* Content committee: [http://meego.com/users/hohndel Dirk Hohndel] (coordination), [http://meego.com/users/thiago Thiago Macieira], [http://meego.com/users/mmeeks Michael Meeks] and [http://meego.com/users/stskeeps Carsten Munk].

=== Sponsoring Committee ===

The Sponsoring Committee is in charge of reviewing the sponsorship requests sent by individuals registering to the conference. It is formed by five members: [http://meego.com/users/qgil Quim Gil] (coordinator, [http://wiki.meego.com/Community_Office Community Office]), [http://meego.com/users/dawnfoster Dawn Foster] ([http://wiki.meego.com/Community_Office Community Office]), Angela Brown (Linux Foundation), [http://meego.com/users/slaine Glen Gray] (Moblin/netbook bg) and [http://meego.com/users/jaffa Andrew Flegg] (Maemo/handset bg).

== Volunteering ==

To run a smooth and successful MeeGo Conference will require a number of volunteers. If you want to volunteer for a certain part of the conference, please add your name below that heading, linked to your meego.com profile. You can follow the conference organization work at the [http://forum.meego.com/forumdisplay.php?f=5 Community Matters forum] (specifically [http://forum.meego.com/showthread.php?t=95 this thread]).

=== General ===
Not sure where you want to volunteer yet until the conference schedule is finalized? Put your name here and we'll add more detailed volunteer tables in the months to come.

'''Volunteers:''' [http://meego.com/users/dneary Dave Neary/dneary], [http://meego.com/users/texrat Randall Arnold/Texrat], [http://meego.com/users/chippy Steve Paine/Chippy], [http://meego.com/users/timsamoff Tim Samoff/timsamoff], [http://meego.com/users/andreagrandi Andrea Grandi/andy80], [http://meego.com/users/ferwakeup Fernando Martin/ferwakeup], [http://meego.com/users/jnwi Jens Wiik/jnwi], [http://meego.com/users/thp Thomas Perl/thp], [http://meego.com/users/sivan Sivan Greenberg], [http://meego.com/users/anidel Aniello Del Sorbo/anidel], [http://meego.com/users/andrei1089 Andrei Mirestean/andrei1089], [http://meego.com/users/ryanware Ryan Ware/ryanware].

=== Scheduled Opportunities ===
There are a number of volunteer opportunities that people can signup for specific time slots, such as manning the information desk or session tech support. Since the final conference schedule isn't available yet, people can signup for the tasks now and then shift around the times they are available later. These are the types of volunteer opportunities:

* IRC Chat Moderators
* Information Desk Helpers
* Session Tech Support
* Conference Setup - Sunday 14
* Conference Cleanup - Wednesday 17
* Speaker Assistants
* Conference Room Reservation Table
* Hacking Session Helpers

'''Volunteers:'''
* [http://meego.com/users/ferwakeup Fernando Martin/ferwakeup] for Speaker Assistant.
* [http://meego.com/users/leinir Dan Leinir Turthra Jensen] for Conference Setup, Conference Cleanup and Hacking Session Helper (depending on sponsorship)
* [http://meego.com/users/monoceros Francesco Baldassarri] for IRC Chat Moderators, Conference Setup and Conference Cleanup (depending on sponsorship)

=== Organizing Opportunities ===
A number of the conference activities have yet to be fully organized and the conference committee would love help with these tasks. Here is a list of activities still needing to be organized. It might be best to start forum threads for each of the specific organizing tasks and then document here the decisions.

* Organize [[MeeGo_Conference_2010/Early_Bird_Events|Early Bird Events]]
* Organize Hacking Sessions
* Organize Temple Bar Night
* Organize Signup for Guinness Shuttles
* Reach out to local businesses for conference deals

'''Volunteers:'''

* [http://meego.com/users/andreagrandi Andrea Grandi/andy80]: I propose myself for '''Organize [http://wiki.meego.com/MeeGo_Conference_2010/Early_Bird_Events Early Bird Events]'''. I'd like to lead the organization of two days ('''November 13th, 14th''') in the similar way we (Maemo Community) organized the [http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend Barcelona Long Weekend]. More details soon.
* [http://meego.com/users/thp thp] - Early Bird Events w/ Andrea
* [http://meego.com/users/revdkathy RevdKathy]: dependent on sponsorship, but I'm volunteering to run a Conference treasure hunt, and offering any stewarding/running, help-desk type activities I can be useful for.

== Topics ==

Potential themes for the conference which suit a first conference.

; MeeGo for Maemo & Moblin application developers
: Bringing developers from old platform to new
: please define here how the old differs from the new. I am assuming the new platform includes using the Qt framework as the standard, but what else? What is the smooth way to move RPM -> DEB?
; MeeGo for N900 and N8x0 owners
: What is MeeGo in a concrete way? Is it a set of userland libraries and applications that you can run on your N900 in a chrooted environment for example?
: Bring our old power users over
: dual booting a "Meego flash image" on your N?x? device? What about MER?
; New developers coming to MeeGo
: Qt and WRT, and maybe Clutter
; Distributing MeeGo software
: yes, please explain how to do this in light of the current system of uploading Debian packages & promoting?
: What comes after Extras?
; MeeGo platform
: Getting more developers involved in the MeeGo platform, and reaching out to upstream to have a critical mass of MeeGo middleware developers there
; Cool stuff (hardware & software) coming out of Helsinki & Portland
: Target press & new users
; Building a healthy MeeGo community
: Involving Intel and Nokia engineers, upstream, platform hackers, application developers and power users in the MeeGo community - covering things like outreach and events, community infrastructure (including the Technical Steering Group, working groups, council?), social dynamics & policies, and community involvement in product roadmaps, etc
;Testing with MeeGo
:Test development, image creation, test execution and debugging as a smooth ride along development.
;The Community Development Ecosystem around MeeGo (lbt)
: Building against MeeGo - the Maemo and MeeGo community OBSes
: Application development and community application QA - Extras and PPAs(?)
: Experimental development - MeeGo on N8x0

'''''A first draft of the Call for Papers is up: [[MeeGo_Conference_2010/DraftCFP]]'''''

== Other suggestions for the event ==
* 3 days event, 2 days organized by the community and one organized by the companies involved. Developers, platform and power users tracks. --[[User:Vdvsx|Vdvsx]] 22:24, 12 March 2010 (UTC)
* In addition to 20 minute talks and 5 minute lightning talks, a provision for talks that fit in between (10 minutes) --[[User:Texrat|Texrat]] 03:47, 14 March 2010 (UTC)
* team-building, brainstorming exercises on a large scale (like the [http://maemo.nokia.com/news/maemo-co-creation-workshop-video/ Co-Creation Workshop held before Maemo Summit 2009] --[[User:Texrat|Texrat]] 03:47, 14 March 2010 (UTC)
* themed tracks with breakout sessions between X sets of presentations (where X can be number of sessions or time duration). --[[User:Texrat|Texrat]] 05:41, 27 April 2010 (UTC)
* Birds Of Feather [http://en.wikipedia.org/wiki/Birds_of_a_Feather_(computing) (BOFs)]- for casual non formal feature planning and development specification: --[[User:sivan|sivan]]
** A group of people interested in a feature or a process gather around a round table.
** A driver for the discussion presents the topic he wants to spec out or a topic assigned to him to present from the list of process and features desired.
** Input is arriving from participants, and is ironed out as "[http://en.wikipedia.org/wiki/User_story user stories]" , as well as leads, references tips and hints for undertaking the development.
** The driver after finishing the session sets to finish the spec in terms of completeness and publish it on the wiki for peer review of the BOF participants and/or a review board that accepts features and new takes for the project.
* Recognize the '''non-technical''' contributor of the year. This is important since we have so many needs on the community side. --[[User:Texrat|Texrat]] 01:35, 17 August 2010 (UTC)
* Recognize the most popular presentations. There should be a formal survey for every talk and workshop, as well as a summary survey. Use the findings to reward those who stood out. --[[User:Texrat|Texrat]] 01:35, 17 August 2010 (UTC)
* Games. Some sort of intramural sports or activities. Hey, we're in a stadium, right? Let's take advantage! Okay, maybe we can't use the field, but surely we can come up with something... even tug-of-war would be fun --[[User:Texrat|Texrat]] 01:35, 17 August 2010 (UTC)
** Treasure/scavenger hunt for meego goodies and prizes.
* [http://wiki.meego.com/MeeGo_Greeters MeeGo Greeters] would make great volunteers! --[[User:Texrat|Texrat]] 19:58, 31 August 2010 (UTC)

Security Advisories

2010-07-07T21:20:51Z

Ryanware: Created page with '==MeeGo Security Advisories== *MeeGo-SA-10:01.kernel: Multiple Vulnerabilities In Linux Kernel *MeeGo-SA-10:02.texlive: Multiple vulnerabilities in texlive *[[MeeGo-SA-1…'

==MeeGo Security Advisories==

*[[MeeGo-SA-10:01.kernel]]: Multiple Vulnerabilities In Linux Kernel
*[[MeeGo-SA-10:02.texlive]]: Multiple vulnerabilities in texlive
*[[MeeGo-SA-10:03.abrt]]: Vulnerability in abrt
*[[MeeGo-SA-10:04.libmikmod]]: Heap overflow in libmikmod
*[[MeeGo-SA-10:05.aria2]]: Directory traversal vulnerability in aria2
*[[MeeGo-SA-10:06.sudo]]: Improper Environment Handling in sudo
*[[MeeGo-SA-10:07.perl]]: Multiple Vulnerabilities In Perl
*[[MeeGo-SA-10:08.pidgin]]: Denial of Service in Pidgin
*[[MeeGo-SA-10:09.gnomine]]: Improper Permissions for gnomine
*[[MeeGo-SA-10:10.adobe]]: Multiple Vulnerabilities In Adobe Flash

SATemplate

2010-07-05T20:34:31Z

Ryanware: Created page with '==MeeGo Security Advisory Template== The below text is the propose MeeGo Security Advisory template. If you have any questions or concerns, please respond in the Discussion are…'

==MeeGo Security Advisory Template==

The below text is the propose MeeGo Security Advisory template. If you have any questions or concerns, please respond in the Discussion area for this wiki page.

<blockquote>
<pre>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=============================================================================
MeeGo-SA-<2-dig year>:<2-dig seq>.<package name> Security Advisory
MeeGo Project

Topic: <short summary>

Category: <high-level category name such as company or org>
Module: <specific packages affected>
Announced: <announcement date>
Affects: <MeeGo releases affected>
Corrected: <date last updated>
CVE: <CVE list if applicable>

For general information regarding MeeGo Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://www.MeeGo.com/>.

I. Background

<Background information on the security issue.>

II. Problem Description

<Detailed description of the issues.>

III. Impact

<What the potential impact of the security issue is.>

IV. Workaround

<Potential workarounds (if any).>

V. Solution

<Description of how to fix the issue. Generally a listing of what
packages to update and the new version numbers.>

VI. References

<References (if applicable).>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iQEcBAEBAgAGBQJMMkFLAAoJECxjfBlj7RcKLewH/jCNCt+zWmHyaNcCnepZGHDX
hNQV7h8bQ5dEE9bT8pkIuEgVzfTg39PfLjF7kY+aNbWuwz4Tm1XnO9MbRO2I05zi
fyLAHgNhpMkx86u7TXbg9Px+xQLS0w6ejPRQoc5QTJrAI2UpZbCXO1HC9ipiyVze
X0+Z2J+OKw59KknvRD9OIHFyYnBEh4SPUSmtCUzhR3sTq75MS5RisvL0H0sRhGYV
s7EJmaQzv7YyqjCGJvBGOZFnZkrDOYUiJ3NpCk4u+CnGwYa3sg8u0q90do/Zu7l0
1wUoz62hhUDP1dNkVhAYeAZ3MVPPPVACypS4M6KKbJ4DfVhYBJqpQM2RY7LFC3o=
=lckT
-----END PGP SIGNATURE-----
</pre>
</blockquote>