Home · All Classes · Grouped Classes · Annotated · Functions

SXE - Application Level Policy

Service Access Control

In general programs may access services, which in the context of the SXE, can mean low level graphical display services provided by QWS to high level Application Services. Service access is achieved by sending IPC calls to the Qtopia system, for example via QCop messages. Application level policy refers to policy which dictates what services a program may and may not access.

In the current implementation of Qtopiacore the IPC calls are in the form of streamed data sent through a Unix Domain Socket (UDS). Currently the entire graphics subsystem is implemented via a system of QWSCommands over this socket, combined with reads/writes to a piece of shared memory.

Because a program requires access to the well known path to the Unix Domain Socket for the QCop system in order to send low-level requests to the Qtopia windowing system, it is not practical to use MAC file system rules to control access to services.

Control of access to services involves two important steps:

  1. authentication : identify profile of the program which sent the request
  2. authorization : check the policy rule for that profile and request

Now the terms program and request require definition.

A downloaded application package may be thought of as containing one program such as a game, or an image manager.

That application may however be made up of a number of binaries, and other files. In some cases a single binary may make up the totality of the package but sometimes the picture is more complex than that.

For example, a game may have a level editor, the main game binary, and a daemon process. While the game itself and the level editor may also be thought of separate applications, both are considered to be part of the same program.

The SXE system applies policy rules to each program component by associating a progId with all the components of that application. The progId has a one to one relationship with the domain the application operates under, therefore all untrusted applications have the same progId while all trusted applications have another.

When a program wants to access functionality available via Qtopia in general it must use the QWSCommand system, or send a QCop message or otherwise ask for an application service. Generally these accesses can be expressed as a string for example in the case of a QCop message requesting a wait indicator to be displayed: QPE/System/notBusy()

Such an access for a service, and the string representing it, is referred to as a request.

Request Authentication and Authorization Procedure

The procedure for authentication and authorization is presented in the following steps:

  1. Process an incoming message:
  2. Determine the progId and hence profile of the program that is sending an incoming message:
  3. Check the policy for the request using the progId:

Program Identification

In the authorization procedure described above it states that the authentication may be done simply if the message transport is trusted.

If the message transport is trusted four assumptions must be fulfilled. The table below lists these assumptions and how, or if, they hold in the Qtopia platform.

AssumptionComments
The transport cannot be intercepted for example, as in a man-in-the-middle attack or traffic-sniffing scenario.Unix domain socket traffic cannot be sniffed or rewritten on a standard Linux kernel. However, the following can be sniffed/intercepted:
  • files
  • UDP
  • shared memory
  • message queues.
The transport end-points cannot be spoofed or subjected to a symlink attack.
  • Unix domain socket end-points can be subjected to symlink attack and process identity can be spoofed; but both of these can be prevented using specifically crafted MAC kernel rules.
  • Files are subject to symlink attacks, and IP endpoints can be spoofed, though TCP will break down since the syn/ack will not work.
  • The kernel will ensure the identifier key for message queues
The transport is reliable and well-behaved as determined by the platforms kernel and/or network stack
  • UDP is not reliable, other transports generally are.
  • Kernels should be audited and supplied by trusted partners.
The client program cannot be compromised for example by an LD_PRELOAD attack or by directly accessing the binary image file on disk
  • MAC rules can prevent accesses to the binaries.
  • If access is prevented the LD_PRELOAD attack is not a problem but there may be some cases where a binary needs to be launched by an untrusted program. This seems unlikely but if so, the MAC kernel can be specifically configured to clean the environment passed to execve

Note: Current QCop messaging (which is used for almost all service requests in Qtopia) uses Unix Domain Sockets.

Summarizing the above table

If the assumptions hold - the kernel and MAC controls can be relied upon to prevent a range of security risks - a simple password-based mechanism can be used at connection setup time to authenticate the connection, or Unix Domain Socket ancillary data can be used.

The second option is more complex than the password method, and carries a portability warning. However if the Unix Domain Sockets rights methods are required for passing file handles that method can be used.

In several scenarios where one or two of these assumptions are not valid the password based mechanism can be simply expanded to HMAC-MD5 message authentication.


Copyright © 2008 Nokia Trademarks
Qtopia 4.3.3