API "sandboxing" on ACCESS Linux Platform is achieved using the Security Policy Framework (SPF), a key component of the Hiker Application Framework. The SPF is a flexible tool that allows device manufacturers, carriers, and others to express a wide variety of security policy decisions in a declarative, rather than programmatic, manner. Traditionally, security policies have been hard-coded into an application or operating system. While this is acceptable in an environment where a development organization communicates directly with its customers, it is less so in the modern mobile device market where long value-chains are the norm and operating system and application developers tend to be several steps removed from the end user. The objective of the Security Policy Framework is to abstract the definition of security policy so it may be "declared" by a stake-holder closer to the end user, while allowing the code that enforces the policy decision to be written by a stake-holder closer to the operating system. With the Security Policy Framework, operating system and application developers don't have to know the exact security policies desired by their end users. As well, device manufactures can provide a system that implements the enhanced security required by corporate customers, but leave it turned off when delivered to a more casual consumer.
To achieve this goal, the Security Policy Framework provides an API that allows you to query the current effective security policy and take appropriate action. See <hiker/security.h> for the APIs exposed by the Security Policy Framework.
Security Policies
Table 13.1 details a sample set of security policies. Note that the actual policies that may be present on a given ACCESS Linux Platform device may be quite different. Policies are not limited to controlling those areas listed in the table; other technologies—the Bundle Manager, for instance—are likely to come under the control of one or more security policies.
The policies illustrated in the table below are defined as follows:
- Unsigned policy
- This is the default policy for unsigned applications and bundles.
- Signed
- This is for applications and bundles signed with a specific key designated to third-party developers.
IMPORTANT: Policy values for unsigned applications are subject to change by ACCESS, the carrier, or the device manufacturer.
Table 13.1 Sample security policiesĀ
NOTE: File access is enforced by LSM. If an application does not have access permissions to any of the PIM application directories, then the APIs that access these directories (such as the ones used to access the PIM databases) are also denied access.
Signing Your Application
The ACCESS Linux Platform SDK includes the Sign Tool, which creates a digital signature and applies it to a bundle. Signatures on ACCESS Linux Platform bundles are used to verify that the contents of a bundle have been in the physical presence of someone who controls the signing key pair, and that the contents have not been modified since that time. Note that a signature applied to an executable in an installed bundle does not automatically imply that the code itself is more or less trusted. It does, however, provide a high degree of assurance as to the integrity of a bundle's contents and in some cases, a high degree of confidence in the identity of the signer. These two components, the identity of the signer and the integrity of the bundle's contents, are used by the Security Policy Framework to determine the degree to which a bundle is signed.
The Signing Process
Before using the Sign Tool, you should have already generated a key pair and certified the public key with a stake-holder. ACCESS will be coordinating the certification process, so developers will know how to get their certificates and keys and how to sign their bundles.
During development you can use a self-signed certificate. Or, you can use the sample key pair and certificate provided with the SDK. To simplify the development and testing process, the standard ACCESS Development Suite makefiles routinely sign your code using these sample keys and certificate.
Once you have a key pair and certificate, the basic process is as follows:
- The developer writes the application source files (
.c,.cpp,.h,.xsd, etc.) using various text editors, Integrated Development Environment tools, and resource editors. - These source files are converted into binary executables and resource files using compilers and other such tools. For an ACCESS Linux Platform application, the output of this step is a bundle.
- The bundle is signed using the Sign Tool. The Sign Tool produces a Security Manifest File (
security.xml) which contains the bundle's signature and adds this file to the bundle's root-level directory.
Note that steps 2 and 3 are typically performed in a single operation when using an automated build system such as make.
Sign Tool
The Sign Tool requires the following to exist before it can function:
- The ACCESS Linux Platform bundle that you created.
- The X.509 certificate and private key, supplied by ACCESS.
The Sign Tool Command Line Interface
The Sign Tool runs from within Scratchbox. See "Signing With the Test Certificate and Key" for an example of how to use this tool. The syntax of this tool is:
alp-sign bundle_directory certificate_file private_key_file passphrase app_name
-
bundle_directory - The directory path of where the bundle to be signed resides.For instance,
~/myApps/MiniPlayer/build/alp-device/com.access.apps.miniplayer.
NOTE: For testing purposes, you can use the test certificate supplied with the ACCESS Linux Platform SDK.
-
certificate_file - The file containing the X.509 certificate.
-
private_key_file - The file containing the private key.
-
passphrase - The passphrase of the private key.
-
app_name - The name of the application, as specified by the
<name>tag that is under the<application>tag in themanifest.xmlfile.
Signing With the Test Certificate and Key
ACCESS Linux Platform applications created using the templates provided with the ACCESS Development Suite are automatically signed using the test certificate (which acts as the root certificate for testing purposes) and key when the application is built; the template makefiles contain a step that does this for you. This certificate and key is provided for testing purposes only, and can be found in the samples directory:
NOTE: The above paths assume that you are within Scratchbox. From outside of Scratchbox, you can find the key and certificate in the
/opt/alp-dev/sdk/samples/ directory.
In addition to the private key and certificate, Sign Tool needs the path to the directory containing your bundle, the name of your application, and a passphrase. The passphrase used with the self-signed test private key and certificate is "accesstest" (without the quotes).
Sign Tool Usage Example
As an example of how alp-sign is used, the following command would be used to sign the MiniPlayer application:
alp-sign build/alp-device/com.access.apps.miniplayer /scratchbox/ALP/samples/ certificate /scratchbox/ALP/samples/key accesstest miniplayer
Note that the above command should be entered all on one line. In addition, you need to be in the directory containing the MiniPlayer application (such as ~/myApps/MiniPlayer) before issuing the above command.
Bundle Installation
The Bundle Manager is the channel through which all third-party applications are distributed and loaded on to a device. The server component of the Bundle Manager is intended to be the only software on the device which has permission to access the bundle folder on the internal file system, requiring interaction with the Bundle Manager for installation or removal.
NOTE: A dialog about an unconfirmed bundle displays if the bundle is not signed or if the certificate is not valid. If this occurs, you should confirm that the signing process was done correctly.
Security checks are integrated with appropriate bundle types, verifying the integrity of signed code, and helping the Application Server to grant additional authority to applications running from appropriately signed bundles.
When a bundle is installed, the Bundle Manager examines the certificate used to sign the bundle (if any) and notes which policy the certificate is associated with. It then verifies the bundle's signature. If signature verification fails, the bundle is treated as if it was unsigned. Otherwise, the Security Policy Framework assigns the bundle a unique package ID, a unique UID (user identifier) that will be used when the enclosed application is run, and the GID (group identifier) associated with the security policy corresponding to the bundle's certificate. This GID, like the UID, will be assigned to the application's process when the application is launched.
SPF and POSIX Group File Permissions
There are two families of enforcement mechanisms used by ACCESS Linux Platform: the Security Policy Framework (SPF) and POSIX Group File Permissions. The two are complementary to each other; developers should use both families of enforcement primitives. In order to complement each other, there is a mapping between the two to ensure that the system properly enforces system security policies.
The SPF allows system developers to identify distinct security policies that "dominate" sets of applications. System policies confer access rights to sensitive system resources and define security-related preferences. Enforcement mechanisms inside the Security Service LSM module, the User-Mode Security Service, and in applications themselves refer to the policy database to determine whether a particular access to a controlled resource is allowed. The system can have multiple security policies, each specifying a different level of trust and privilege. The enforcement primitives inside the security service use the application id or the public key used to digitally sign an application as the key to find the proper policy. An application from ACCESS, for instance, would likely be more trusted than an unsigned application from the Internet, so it therefore is given more privilege.
The benefits of the Security Policy Framework are that it is flexible (any developer may make use of its features) and can be remotely managed. The SPF may also be used to control access to resources traditionally not covered by the POSIX model.
