Home · All Namespaces · All Classes · Grouped Classes · Modules · 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 Qt Extended 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 Qt Embedded 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 Qt Extended 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:

authentication : identify profile of the program which sent the request
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 Qt Extended 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:

Process an incoming message:
- Verify that the message is a valid message
- If the transport is untrusted, confirming validity requires a Message Authentication Code.
- Check if authentication information is included
- Un-marshall the message and prepare to process the request
- if the request is in an allow whitelist, procedure complete, process request
Determine the progId and hence profile of the program that is sending an incoming message:
- if the message transport is trusted either a simple shared secret or Unix domain socket ancillary data identification will suffice.
- if the message transport is connection oriented the program identity may be cached against the file descriptor or other identifier for the connection.
- the program identity need only be extracted from authentication information included in the message once validity is confirmed
- if the shared secret is incorrect then
  - deny any requests not in the allow list.
  - if a threshold of 5 or more failed authentications in minute occurs, log a security breach to lockdown all downloaded applications. See SxeMonitor
Check the policy for the request using the progId:
- look up the security profile/domain awarded to that progId in sxe.policy.
- look up the list of requests allowed for that profile in sxe.profiles.
- if the request is in one of the profiles the message is processed normally.
- if the request is not in one of those profiles:
  - deny the request
  - log the security breach so that SxeMonitor can respond

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 Qt Extended Base module.

Assumption	Comments
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 Qt Extended) 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.

Trademarks

Qt Extended 4.4.3