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

SXE - Application checklist

For an application to run correctly on an sxe-enabled device the following requirements should be observed. These apply to both pre-installed and downloaded applications.

Requirements

Source Code Requirements

• To correctly key an application, a couple of SXE related macros need to be used. The simplest and preferred way to do this is to use the QTOPIA_MAIN macro which implicitly calls the SXE macros:

      QTOPIA_ADD_APPLICATION(QTOPIA_TARGET,Example)
      QTOPIA_MAIN

  otherwise an application can explicitly use the QSXE_APP_KEY and QSXE_SET_APP_KEY() macros as shown below:

      // make will fail without this!
      QSXE_APP_KEY
  
      int MAIN_FUNC( int argc, char **argv )
      {
          // This is required to load the SXE key into memory
          QSXE_SET_APP_KEY(argv[0]);
  
          QtopiaApplication a( argc, argv );
          ...

  (MAIN_FUNC resolves to main, the code snippet comes from examples/manual_main/main.cpp)

Project file(qbuild.pro) Requirements

• An application should typically declare itself a Qt Extended application in the project file

      # This is an application
      TEMPLATE=app
  
      # The binary name
      TARGET=example

• The application needs to declare which domain it will be using in the project file:

      # SXE information
      target [
          hint=sxe
          domain=untrusted
      ]

The above requirements refer specifically to Qt Extended applications which communicate with the qpe server and make requests. Binaries which do not communicate with the server do not need to do these steps. They still need to declare a domain however and are bound by the MAC rules that domain imposes.

Note: SXE does not support running pure Qt/Embedded applications with Qt Extended.

Qpk packages and SXE

There are a number of caveats to be aware of when installing qpk packages on an SXE configured Qt Extended.

• SXE is only supports the download and running of games, packages are limited to the set of functionality outlined in SXE - Aims and Limitations.
• Packages have write access to their own sandbox directory and read-only access to system libraries and other miscellaneous files. An exception to this is the bin directory inside the sandbox which is read-only from the package's point of view. Packages do not have access to the /tmp directory therefore any data or temporary files should be created using Qtopia::sandboxDir() which returns the package's sandbox directory. There may be issues when using classes like QUniqueID and QUniqueIDGenerator which implicitly uses files outside the sandbox. Likewise using it is advised that QTemporaryFile not be used.
• Settings files will automatically be created for a package in it's own directory, see Qpk Packages for details.
• Packages are not allowed to run scripts.
• Packages created by both non-SXE and SXE configured builds of Qt Extended can be installed onto an SXE enabled device, provided the aforementioned requirements are met.

Understanding security violations

For untrusted applications, as long as functionality is limited to that described in SXE - Aims and Limitations, a developer generally should not run into any issues with SXE. However, on occasion code may be written which causes an application to violate policy. When an application breaches security policy, the SxeMonitor will act to kill the errant process and send a synthetic SMS to the user (provided security logging has been correctly configured).

The synthetic SMS will contain the violation. Application level violations are of the form:

    Violation: Request for foo was denied

where foo is the denied request string.

Another way of determining the violation is to lookup the console/Qtopia log output where the request denial will be of the form

    foo - denied: for Program Id 2 [PID 3476]

This method can be used even even if security logging has not been correctly setup. These kinds of violations occur if a service request has been made that is not allowed in the application's declared domain. sxe.profiles contains the definitive list of requests allowed in a given domain.

OS level violations can vary but the most common type is

    Violation: Attempt to open foo for writing

The corresponding log entry is of the form:

    LIDS: bar (dev 100:32 inode 4119) pid 6027 ppid 1112 uid/gid (0/0) on (null tty) : Attempt to open foo for writing

where foo is the path to a protected file and bar is an executable breaching policy. Security logging must be setup in order to see LIDS violations.

Once the violation has been identified, it may be used to help identify what the offending code is. For downloaded applications the script sxe_sandbox and the scripts under sxe_domains are the definitive guide for the OS level access granted to a domain. Applications pre-installed in the Qt Extended image should never receive LIDS violations.

FAQ

Q: I'm working with Qt Extended on a desktop environment, I have used the SXE macros and when I run my binary it gives me the error: SXE key has not been set.

A: Ensure that the binary you are running is from the Qt Extended image directory, as this is where the keyed binaries are placed after a qbuild image