SXE - SxeMonitor

Introduction

As part of the SXE, a privileged Qt Extended system process known as SxeMonitor monitors security. SxeMonitor runs as a lightweight process that responds to security policy breaches. If an an untrusted application breaches policy the following steps are taken:

• The errant application is terminated.
• The errant application is disabled to prevent restart
• The user is notifed via dialog
• The user is sent a notification via synthetic SMS.

The Package Manager can be used to re-enable a disabled application.

Deleting or uninstalling the application automatically may not be desirable as:

• if the application is DRM controlled, removal of the rights object may mean the application cannot be accessed by the user without paying for the DRM controlled package again
• if the user has created content, using the application that content may be inaccessible after uninstalling the application
• given that the program is flawed or malicious the SXE system could ask the user to forward the package for analysis:
  • to protect the user from for example being unfairly billed by a network provider
  • to counter further spread or activity of the program.

If suspicous activity is detected but there is difficulty in isolating the errant application, then a lockdown state is initiated which:

• Terminates all untrusted applications
• Disables all untrusted applications
• Notify the user via dialog
• Notify the user via synthetic SMS

A scenario when this might happen is during a brute force attack to guess the keys of trusted programs, if the number of negative authentications exceed the false authentication rate (currently hardcoded to 5 per minute), then all downloaded applications terminated and disabled.

Breaches are communicated to the SxeMonitor via a security log. The log serves to decouple the SxeMonitor from the rest of the Qt Extended system so that the integrity of the monitor is maintained even if other parts of Qt Extended are compromised or exploited. The cost of this decoupling is the time to react, as preiviously mentioned it is possible that an errant forked process can die before the SxeMonitor has a chance to identify what program it belonged to, nevertheless malicous programs still will not have access to any sensitive resources.

Configuration

The SxeMonitor can be configured through the Sxe.conf which is located in /devices/etc/default/Trolltech. In the Log Group, the following parameters may be specified

Parameter	Purpose
Size	Maximum size of the log file in bytes
Path	Path to where the log file is located
StampFormat	Regular expression representing the format of the log stamp for Qt Extended security messages
LidsStampFormat	Regular expression representing the format of the log stamp of LIDS related security messages

An example Log group entry is shown below:

    [Log]
    Size = 1048576
    Path = /mnt/documents/.log/sxe.log
    StampFormat="^([A-Z][a-z]{2}\\s+\\d{1,2}\\s+\\d{2}:\\d{2}:\\d{2}[^:]*qpe:\\s)(.*)$"
    LidsStampFormat="^([A-Z][a-z]{2}\\s+\\d{1,2}\\s+\\d{2}:\\d{2}:\\d{2}[^:]*kernel:\\s)LIDS:.*\\(dev.*\\) pid (\\d*) ppid.*:(.*)$"

See also SXE - System Integration for instructions to set up the security logging on a device.

Development on desktop with qvfb

When developing with an SXE-enabled build of Qt Extended on a desktop with qvfb, a security log should to be setup in order to have the SxeMonitor process take action in the event of a policy breach. If the security log is not set up a warning will be displayed. Processes making illegal requests will still be denied but not be killed. If you are unconcerned about this, the warning can be safely ignored.

To setup the security log, which by default is /var/log/sxe.log, log messages of priority local6.err must be redirected to it and it must give read permissions.

The following steps show how to do the redirection on SuSE10.2 with syslog-ng:

1. Edit the syslog-ng.conf file found in /etc/syslog-ng, create a new filter for the local6 facility and err level, under the Filter definitions section

       filter f_sxemon      { facility(local6) and level(err); };

   and create a new destination and log statement

       destination sxelog{ file("/var/log/sxe.log" group(users) perm(0664)); };
       log { source(src); filter(f_sxemon); destination(sxelog); };

2. To reload the configuration file and ensure the changes will persist after reboot, use the following commands as root.

       /sbin/service syslog restart
       /sbin/chkconfig syslog --level 345

3. To check if the redirection was successful run the following and make sure "arbitrary string" is written into sxe.log

       logger -p local6.err "arbitrary string"

4. You may wish to set up a cron job to periodically clear the contents of the specified log file to prevent it from growing too large

If you wish to specify a log file other than /var/log/sxe.log, then edit the Sxe.conf file and modify Path parameter of the Log group. Ensure that log redirection is applied the specified file.

Also note that on a desktop environment, the Size and LidsStampFormat parameters of the Log group in Sxe.conf are effectively ignored.