Security Policy Enforcement Framework (SPEF) Foundation API
1.0 References[1] Software Architecture Document, Version 1.1 Revision 1.4, LiMo Foundation, 11 September 20072.0 OverviewThe purpose of the Security Policy Enforcement Framework (SPEF) is to provide a means by which applications can be run on the handset in such a way that they can only perform operations and access resources that they have been authorized to use. This is important for applications written or controlled by the hand-set manufacturer or by a 2nd-party in close collaboration with the manufacturer, but it is essential to host 3rd-party applications, especially native code applications, i.e. code that is compiled and runs directly on the platform rather than in an interpreted execution environment.SPEF provides for the specification and enforcement of access control rules for all applications and executables in the system. All processes will be running in a protection domain. These (protection) domains allow grouping of code by level of authorization to access resources and perform operations. Domains can be defined according to the level of trust associated with the software. The level of trust would typically be influenced by the level of manufacturer-defined testing that software undergoes, or by the relationship between the manufacturer and the 3rd party. Domains can be defined where the authorization for software to perform operations and access resources is appropriate for the level of trust. SPEF allows any number of domains. The domains, permissions and policies are described in a set of configuration files, called the Domain and Policy Stores. There are two versions of these, one for protecting kernel resources, and one for protecting user space resources. The two Policy Stores are different, but both Domain Stores are identical. We use two copies because it makes accessing this information easier. Kernel resources are secured by SPEF policy checks by the SPEF LSM code inside the kernel. There is no exposed API for that. User space resources need to be protected by resource manager applications. The picture shows three examples of resource managers, but there can be many more. Access to the resources managed by these resource managers should use a form of IPC (Inter-Process Communication) between client applications and resource managers. The SPEF API allows user space resource managers to perform security checks on operations requested by its clients.
SPEF Architecture Diagram 2.1 Key ConceptsSeveral key concepts are described in the following sections. See Examples for code samples.2.1.1 DomainStoreDomains allow grouping of UEs (units of execution - executables and logical applications) by level of authorization that they are given when accessing resources and performing operations. The Domain Store defines all the domains used for a particular PolicyStore. This should be common for both kernel and user space. The PolicyStore and DomainStore files are created in XML format and converted to binary format by spef_compile utility for runtime performance.2.1.2 MetaStoreThe MetaStore contains descriptions of all permission types that can be used on the device.2.1.3 PolicyStoreThe PolicyStore specifies the actual policy rules to be checked during runtime. It uses the DomainStore definitions of domains, and the MetaStore definitions of permissions.2.1.4 Asynchronous Functions Under DevelopmentThe API describes both the synchronous and asynchronous checker functions. Only the synchronous functions are currently implemented. The asynchronous functions are under development and will allow for input from the end-user to grant or deny a selected set of permissions.3.0 Industry StandardNone4.0 External API DocumentsNone5.0 Plug-in Extension Point InterfaceNone6.0 Other InterfacesNone7.0 Other NotesTheGenerated on Mon Mar 31 01:01:00 2008 by 
1.5.4
|