Home · All Classes · Grouped Classes · Annotated · Functions

SXE - Impact and Implications

The SXE policy has a number of impacts and implications for the following:

• Qtopia Development
• Developers
• OEMs
• Integrators
• Operators
• Performance Effects

These are discussed in detail in the following sections.

Qtopia Development

The SXE provides base system policies, which form part of the Qtopia build system and a set of discovery and tools supplied with SDKs and packages to allow OEMs to build applications and generate policies for them.

From there, policies can be customized by integrators and policy text files may be edited by hand to change the policies.

Developers

There is minimal impact for developers of applications such as games. Such applications typically only access files specifically for that application, such as high score tables, local caches and images.

Applications which require access to either the users documents, such as, pictures, pdfs, mp3s, or to the Qtopia database for PIM applications, must go through the secure document server. There will be a very small restriction on function, and some small additional coding required to do this.

For a more complex application, requiring access to shared files or network services, once development is complete, the application must be run through all its code paths, under the policy discovery tool to see what files it requires access to, and generate policies as required . It is planned to provide an SXE simulator to check that the installed package will run with the generated policy.

Finally, our custom package format must be used. Again this should be automated by the SDK. Some very limited provision will be provided for legacy .ipkg format, but this will not be formally supported and will likely work for only very simple applications such as some games.

OEMs

The impact for OEMs for any applications which are to be shipped outside of the trust framework is as above.

For certified applications, there should be no impact. The intention is that the integrators and OEMs work with a Qtopia 4 SDK the same way they work with current SDKs.

They may wish to provide a support framework to receive any end-user reports of security violations; or they may wish for this to be the responsibility of the network provider.

Integrators

The design and build of the Linux kernel and file-system must now include the Mandatory Access Control(MAC) kernel and its associate user-space binaries: lidsconf and lidsadm. Development of such kernels and file-systems is straightforward and is described in the documentation for LIDS.

Operators

Operators require a higher level of confidence in the integrity of the phone software stack, in the face of down-loadable application scenarios, and virus activity.

With respect to content provision, placement of packages for download will operate with little change, that is, it is OEM configurable.

Violations are detailed in a synthesized email message in the SMS Inbox. Notification of the arrival of the message is as for any other message. The text of the message describes the violation and includes technical data pertaining to the violation. This can then be forwarded to a support number for analysis of the violation.

Automatically uninstalling an application is possible, however currently a violated application will be disabled to allow the user to recover any data first.

Performance Effects

• The proposal for a MAC kernel implementation involves the use of Linux Intrusion Detection System (LIDS).
• The Security Enhanced Linux (SELinux) MAC kernel is currently integrated with 2.6 official Linus kernel sources. It has broad support despite indications of performance decrements of 7% over the normal kernel. SELinux uses file-system extended attributes, such as JFFS and YAFFS, that are not available for embedded file-systems at the time of writing. LIDS is much simpler than SELinux and is expected to perform well.
• Program Identification overheads are only a consideration when asynchronous IPC is being carried out; at which point some overhead is expected and accepted. The marginal or incremental overhead introduced by Program Identification is minimal.

  In many cases Simple authentication can be used, and optimizations are possible such that if key-based identification is required for complex scenarios the incremental addition to IPC end-to-end time is minimal and not noticeable.

• The server process table is in memory and will usually contain less than 10 entries. The installation table exists on storage but is read entirely into memory at run-time. It contains an entry for each currently installed package and one for each Qtopia system binary: entries will be in an order of magnitude of 10^1.
• Full-blown message authentication is intended for more complex service request scenarios, more likely on set-top boxes, video consoles or complex PDA based services rather than low-end phones; although it may be needed for unforeseen applications on more powerful telephony enabled devices in the future.
• For trusted transports, eg QCop messaging on Unix Domain Sockets where the endpoints are protected by MAC rules, simple message authentication only occurs at the time of initial socket connect.
• The current implementation for message authentication is HMAC-MD5 with an option to switch to HMAC-SHA1 for greater security at performance cost. These algorithms are built into the Linux kernel and accessible to Qtopia via a userspace framework; or are shipped with a vendor supplied accelerated cryptographic solution. As a generalization HMAC-MD5 for short messages like QCop is very fast.

  This is only required if an untrusted transport is used, for example if a UDP socket or similar system.

• The current implementation for install time certification uses X509 certificate signatures. The X509 code will be part of an external library, possibly OpenSSL or a proprietary cryptography library optimized for small platforms.
• The application rule-set will contain a row for each message authorized by a program identifier: entries will be in an order of magnitude of 10^2.

  To mitigate performance impact from application rule-set, execution without authentication is used for safe messages, for example, retrieve battery life. Also rule-set lookups are cached and the caching policy maybe adjusted for better performance if memory resources are available.