Home · All Namespaces · All Classes · Grouped Classes · Modules · Functions

SXE - Package Keying and Manifest

There are two registry files governing the operation of the SXE with respect to packages and programs.

All registry files for SXE must be writable and are stored in the directory given by QPackageRegistry::sxeConfPath(). This directory is normally Qtopia::qtopiaDir() + "etc" and the File entry in the tables below are relative to this path.

The table below summarizes the operations of SXE with respect to these files.

Process keys and Program Identities

In order to decide which policy to apply when a service is requested, the Program Identity or progId is used. The progId is a key into the policy lookup table.

Conceptually a program is a binary (or binaries) on disk. When a package is installed its program binaries are copied into place in a directory on disk (or flash) storage to later be launched. One progId is used by all binaries of a package, since all binaries in the package have the same set of security domains.

When a program binary is launched as an instance, it is a process in execution. At that point it has a Unix process id or pid.

The process must transmit a Program Identity to request a service.

So that the server providing the service can know that the process is authorized to use that progId, the process must also transmit the Process Key or key.

The server can lookup to see if the key matches one of the keys allocated to that progId. This constitutes authenticating the process.

Key Propagation

In order for keys to work as an authentication mechanism, they must be a shared secret between the process, which is executing a given program, and the server, which is doing the authentication.

Here shared secret means that no other process can have the key; but both the client and server of the service must have it.

Achieving this state is not a trivial problem, but when it is achieved it makes authentication secure, simple and fast. No further lookup is required, since possession of the key guarantees authentication.

SXE achieves key propagation by relying on the LIDS kernel patch as modified for Qt Extended.

The client can read its key from /proc/1234/lids_key where 1234 is the Unix pid of that process. Keys are created in these pseudo files when the process is launched, and the kernel enforces that only the process itself (in this case process pid 1234) can read its own key.

This technique means that no LIDS rules are required to protect each key, since it is automatically exclusive to the process. Also problems relating to read only file systems are solved.

The server can read the keys for all processes from /proc/lids/keys. This pseudo file is updated by the kernel will the keys, and the device id and inode number of the binary. The pseudo file is protected by a LIDS MAC rule to prevent untrusted processes from reading it.

The Development Case

On the desktop development environment, the /proc/lids/keys pseudo file is not available, and nor are the per-process pseudo files, obviously because the desktop machine does not have the Qt Extended LIDS kernel patch.

In this case, a fallback method simulates the pseudo files by using on-disk files with the exact same format. These disk files are read by the server.

This is similar in concept to how instead of /dev/fb0 the virtual frame buffer is used on the desktop.

The files used in the development case are:

For the clients to each know their key, in the development (not in the live) case, the key is embedded into the binary image of the file.

In general this method is not suitable to be used on the device, since in the case of read-only devices, the key is not able to be changed from the ROM image.

A malicious hacker who obtains a copy of the ROM image (eg by manually cracking a phone in his possession) can then know the keys for a large number of devices.