The Hiker Security Components

Security Policy Framework/Security Module

The Security Policy Framework (SPF) is the component which controls the security policy for the device. The actual policy used by the framework is created by a licensee and can be updated. Policy is flexible and separate from the mechanisms used to enforce it. The policy can express a wide (and extensible) range of policy attributes. Typical elements of a policy address use of file system resources, network resources, password restriction policies, access to network services, etc.

Each policy is a combination of these attributes and is tied to a particular digital signature. Applications are checked for a digital signature (including no signature or a self-signature) and an appropriate security policy is applied to the application. One of the policy decisions that can be made by the framework is whether the user should be consulted – this allows for end-users to control access to various types of data on the device and ensure that malicious applications will not access this data covertly. Other types of decisions are allow/deny which may be more appropriate for a carrier to use to protect access to network resources, etc.

The ALP LSM (Linux Security Module) is a kernel level enforcement component that works in concert with the SPF. The LSM controls the actual access to files, devices and network resources. Because it is an in-kernel component, the LSM has been released under the GPL v2.

There must be some user control on who is allowed to connect to the user's device and request action from it. Security is mostly based on the user control at the following levels:

There will be default handlers (implemented by in the box PIM apps) for a bunch of published standard services. In the event where a third party application would try to register a duplicate handler, and the first handler declared it wanted to be unique, the user would be alerted and asked to arbitrate which application should be the installed handler. The user is the authority that tells the system which handler wins in case of conflict. This security works whichever handler installs first. In a model where all installed apps are signed and therefore trusted, we can rely on what the application do when they register.
When there is a non-authenticated incoming connection, the user is asked to authorize the connection. Local is obviously initiated by the user and is always valid. IR is considered authenticated, as the user must explicitly direct his device to the initiator. Paired Bluetooth is authenticated by definition. SMS is authenticated by the mobile network. TCP may be considered authenticate if the source IP address figures in the table of trusted sources (although this may be discussed as it is easy to spoof the source IP). TCP may also be configured to require a challenge password before it accepts to read from the connection.
Above the connection level authentication, handlers may also require permission from the user before they perform their action. This is handler specific. 'get vCard' is obviously a very good candidate to user authorization.

Back to "About Hiker... "