IT tutorials
 
Mobile
 

Symbian OS : Security - Secure Agent

5/9/2013 3:15:28 AM
- Windows 10 Product Activation Keys Free 2019
- How to active Windows 8 without product key
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

1. Problem

1.1. Context

You are developing an application or service which includes functionality requiring high security privileges together with a similar or greater proportion of functionality which can run with lesser or no security privileges.

1.2. Summary
  • It is more difficult to find and fix security vulnerabilities in components which include both security-critical and other code ('economy of mechanism').

  • Developers of components which require high security privileges should minimize any liability they may be exposed to due to errors in design or implementation ('least privilege').

  • You wish to make it as easy as possible to create and distribute updates to your code.

  • When using any security privilege, but especially the device-manufacturer-approved capabilities, you are required to ensure that the privileges are not leaked and unauthorized software cannot use them.

1.3. Description

The most straightforward architecture for an application or service may be to structure it as a single Symbian OS process or device driver; however if some of its functions require device manufacturer capabilities such as TCB, AllFiles or DRM there are likely to be longer-term drawbacks in having the highly trusted parts of your component executing in the same process context as the less critical parts.

When both highly privileged and non-privileged code are intermingled in the same process context, any analysis looking for security vulnerabilities has to consider all of the code as equally likely to be a potential source of a vulnerability.When all of the code is running with the same set of capabilities, a vulnerability anywhere in the code could potentially be exploited to use the most sensitive APIs and data accessible by the process. Also, when all the code is packaged for certification and signing as a single component, changes anywhere in the code may lead to the entire component needing to be recertified as requiring the device manufacturer capabilities and not just the highly privileged code. This is true even if the code is separated out into different DLLs since the DLL loading rule would require them to have any device manufacturer capability that the process that loads them does.


1.4. Example

The Symbian OS software installer (SWI) is one of the most critical parts of the platform security architecture. It has, in effect, the highest level of security privileges and therefore needs to be trusted at the highest level; it is part of the Trusted Computing Base (TCB) [DoD, 1985] and malicious functionality injected into the TCB can do anything it wants.

At the same time, the software install subsystem covers a lot of functionality that should not be security-critical; it is desirable for clients without device manufacturer capabilities to be able to invoke the software installer and supply a package using various communication and storage mechanisms; it is only necessary that the package being installed correctly passes security checks. The client is also likely to make use of DLLs which are not granted the TCB capability, and thus could not be linked in to a process which has been assigned that capability. This is because almost all the DLLs provided by Symbian OS have all capabilities except for TCB, precisely so that they can be widely used but do not have to be audited for use within the TCB.

2. Solution

Divide your software component into two or more components, with at least one component containing code which is security-critical, and one or more components containing code which is not security-critical. Security-critical code should include both code which requires high security privileges to execute[] and code which checks the correctness of input data affecting security-related operations. For example, non-critical code could include user-interface components and application logic which only requires access to the application's own private data.

Dividing your software component into two or more components which execute as separate processes allows each component to be given only the capabilities which it needs to perform the subset of functionality which it implements. By introducing additional processes, each with their own isolated memory spaces, you minimize the damage that can result from a security vulnerability in one component ('principle of least privilege').

Such separation enables closer scrutiny and analysis of the security-critical code, increasing confidence that vulnerabilities will not be found after the software has been deployed. This practice of minimizing the size of highly trusted code is a well-established security principle ('economy of mechanism').

If your component is distributed as an installable package (a SIS file), it will need to be signed by a trusted authority[] to be granted capabilities. When high security privileges are needed, such as TCB or other device manufacturer capabilities, there are additional steps in the signing process. Packaging the security-critical parts of your component in a separate SIS file allows updates to, and new versions of, the noncritical parts to be created and distributed without requiring the overhead of device manufacturer approval for the new code and hence avoids any additional cost or time so expediting the deployment of urgent fixes.

2.1. Structure

Non-critical code and security-critical code are separated into two communicating processes to create two different memory spaces that are isolated from outside interference (see Figure 1). This can be achieved with an architecture including two user-mode processes, perhaps using Client–Server (see page 182) for the communication between them or, where it is necessary to have code execute in kernel space, implementing the security-critical code as a device driver which communicates with non-critical components running in a user-space process.

The process containing the security-critical components should never simply expose a public API equivalent to an existing API requiring high security privileges to access; if this were the case then any client of that API would have to be just as trusted as the secure agent itself, since any vulnerability in the client could be exploited by an attacker to do the same thing as they could by exploiting a vulnerability in the agent.

2.2. Dynamics

Malicious software may attempt to call the secure agent's API as a way of gaining access to protected services or data. The interface between the security-critical and non-critical components must therefore be carefully designed to ensure that communication across the process boundary does not allow unauthorized use of the privileged operations performed by the security-critical components. This undesirable consequence is known as 'privilege leakage', and there are two measures which can be implemented inside the security-critical components to avoid it occurring:

Figure 1. Structure of the Secure Agent pattern

  • Ensuring that only authenticated clients are allowed to invoke the security-critical components, for example, by checking that the client has a particular SID from the protected range, mitigates the risk of malicious software impersonating an authorized client and taking advantage of the APIs exposed by the security-critical components.

  • Validating the parameters passed to the security-critical components to ensure that they are within expected ranges mitigates the risk of security vulnerabilities caused by unexpected values whether they come from logic errors, user input errors or deliberately exploited security vulnerabilities in an authorized client. Such validation would also include, for example, checking digital signatures on data if the data is expected to be coming from a trusted source.

Figure 2 shows the interaction of the non-critical and security-critical processes.

Figure 2. Dynamics of the Secure Agent pattern

The client process first creates a session with the secure agent which may cause it to be started, if it is not already running. The secure agent can perform a one-off set of checks on the authenticity of the client at this point or can check each service request individually. These checks can include verification of the identity of the client process, via its SID or VID, or that it has been trusted with sufficient capabilities.

When the client invokes the secure agent API to perform actions on its behalf, it can pass parameters with the request that might include, for example, basic types, descriptors, and file handles. For each action, the secure agent is responsible for checking the validity of the parameters and any input data read from locations, such as files, provided by the client.

2.3. Implementation

Client

The MMP file for the client should look something like this:

TARGET        myapp.exe
TARGETTYPE    exe
UID           0 0x200171FD // Protected-range SID

CAPABILITY    NetworkServices, ReadUserData // User capabilities

SOURCEPATH    .
SOURCE        myapp_ui.cpp
SOURCE        myapp_logic.cpp
SOURCE        myapp_ipc.cpp

USERINCLUDE   .
SYSTEMINCLUDE \epoc32\include

LIBRARY       euser.lib

In this example, the client part of the application requires only user-grantable capabilities which do not require to be signed for. Note, however, that it specifies a protected-range SID which the secure agent can use to authenticate the client, and therefore it needs to be delivered in a signed SIS file.

Secure Agent

The MMP file for the secure agent should look something like this:

TARGET        secagent.exe
TARGETTYPE    exe
UID           0 0x200171FE // Protected-range SID

CAPABILITY    AllFiles // Device manufacturer capability

SOURCEPATH    .
SOURCE        secagent_api.cpp
SOURCE        secagent_validation.cpp
SOURCE        secagent_operations.cpp

USERINCLUDE   .
SYSTEMINCLUDE \epoc32\include

LIBRARY       euser.lib
LIBRARY       efsrv.lib // Includes APIs requiring AllFiles

The secure agent is built as a separate executable. In this example, it requires a device-manufacturer-approved capability, AllFiles, so it must either be pre-installed in the device ROM or delivered in a signed SIS file that is approved by the device manufacturer.

Inter-Process Communication

Implementing this pattern requires the introduction of a secure IPC mechanism. Symbian OS provides a number of mechanisms which you can use to provide this, such as Publish and Subscribe (see page 114), if you need a relatively simple, event-driven style of communication, or Client–Server (see page 182), which supports a more extensive communication style. Which of the various mechanisms you use depends on exactly what needs to be communicated between the client and the secure agent.

2.4. Consequences

Positives

  • It is easier to concentrate review and testing on the security-critical code, making it more likely that any security vulnerabilities are found before software has been deployed hence reducing your maintenance costs.

  • The amount of code running with high security privileges is reduced, making it less likely that there will be undiscovered security vulnerabilities.

  • It is easier for signing authorities to assess functionality and grant sensitive capabilities because the amount of code requiring special approval for signing is reduced.

  • It is possible to develop and quickly deploy updates to non-critical components without needing to resubmit code for signing approval.

Negatives

  • Increased development effort is required at the design stage to divide the functionality into suitable components and to define appropriate APIs for communication between the non-critical and security-critical parts.

  • Debugging may be more complex because of the need to trace the flow of control between multiple processes.

  • An additional attack surface has been added which can reduce the security benefits.

  • The code size of your components will be increased to manage IPC and validate parameters.

  • RAM usage will be increased due to the addition of an extra process (a default minimum RAM cost of 21–34 KB[]), the increased code size (to implement the IPC channel and the validation of the IPC messages), and the additional objects required in your components and in the kernel to support the IPC.[]


  • Creation of a separate process, marshalling of IPC, parameter validation and additional context switching between the client and the secure agent decreases execution speed.20

2.5. Example Resolved

The Symbian OS software installer uses this pattern (see Figure 3) to separate out the less-trusted software install functionality, such as reading, decompressing and parsing the SIS file and handling the user interface, to be run as part of the client process. The more-trusted functionality that requires TCB privileges, to write the contents of a SIS file to the file system and update the registry of installed applications, is run as a separate process.

Figure 3. Structure of the Software Installer pattern

The client process, which only needs the TrustedUI capability,[] communicates with the SWI Server using Client–Server (see page 182) to provide the IPC between the two processes (see Figure 4). The main purpose of the SIS Helper component in the client is to facilitate this communication. The SWI Server runs with all capabilities including TCB, DRM and AllFiles as these are needed in order to extract install binaries into the system directories on the mobile device.


Figure 4. Dynamics of the Software Installer pattern

3. Other Known Uses

  • Malware Scanners

    Malware scanners are applications that include an engine to scan for malware as well as components that manage the over-the-air update of malware signature databases and user-interface functionality such as control panels. Only the scanning engine requires high privileges and so it is separated from the other functionality which resides in its own process. The scanning engine however is loaded into the Symbian OS file server process as a PXT plug-in via Buckle (see page 252). As the file server is part of the Symbian OS TCB, DLLs it loads, such as these plug-ins, are required to have the TCB capability. Malware scanner vendors typically package the file server scanning engine plug-in in a SIS file signed with TCB capability, and deliver other components in a separate SIS file that can be updated frequently and easily. So that only a single package needs to be delivered, the scanning engine SIS file can be embedded inside the SIS file for the full package without the need for the outer SIS file package to be signed with device manufacturer capabilities.

    Note that the scanning engine is responsible for making sure that any updates done to its database are legitimate before accepting them; end-to-end security of such data updates is typically done by validating a digital signature on the update.

  • Symbian Debug Security Server

    A further example of this pattern that includes highly trusted code running in the kernel is the Symbian Debug Security Server, introduced in Symbian OS v9.4. The low-level operations of the debugger (reading and writing registers and memory belonging to the debugger process, suspending and resuming threads, etc.) are implemented in a Logical Device Driver (LDD) called the Debug Driver, which represents the Secure Agent as described in this pattern. The device driver provides the low-level functions to a process running in user mode called the Debug Security Server. When started, the Debug Driver checks the SID of the client to ensure it is the Debug Security Server so that only this authorized process can access it. The Debug Security Server in turn checks the SID of its clients to ensure that it only provides debug services to authorized debuggers. The Debug Security Server uses a security policy based on access tokens and process capabilities to ensure that a debugger client is only able to access those processes it is authorized for.

4. Variants and Extensions

  • Separating Security-Enforcing Code from Highly Privileged Code

    In some ways, the desire to group together security-critical code, such as the TCB, to allow in-depth security evaluation is in tension with the desire to isolate code that requires high security privileges to perform its function according to the principle of least privilege. To resolve this tension it may be helpful to consider separating a software component into three subsets (see Figure 5).

    It is possible to extend the Secure Agent pattern to architect an application or service as three communicating processes. The benefits of separately considering the security characteristics of the trusted code (including both security-enforcing and highly privileged code) are maximized by being able to exclude the non-critical code from security review. The benefits of the 'least privilege' principle are maximized by separating out the security-enforcing code that does not need high security privileges from the code that must be highly privileged to perform its function.

    Figure 5. Separating security-enforcing code from highly privileged code structure

    Factoring the component into three processes, however, magnifies all of the negative consequences listed above so this more complex approach is best reserved for situations where security is of paramount importance. Something analogous to this can be seen in the Symbian OS platform security architecture [Heath, 2006], where the TCB is limited to that functionality which absolutely has to run with the highest privileges and a lot of security-enforcing functionality is provided by system servers in the TCE, which run with only the specific system capabilities they need.

  • Open-Access Secure Agent

    Where the secure agent can safely provide services to any client, the authentication step can be omitted. One example of this could be a service which allows unprivileged clients to initiate playback of DRM-protected content without giving the client any access to the protected data itself. The secure agent still needs to include validation checks on the parameters and other data passed to it to ensure that malicious software cannot exploit any vulnerabilities resulting from processing of out-of-range or other unexpected data. The security implications of such a design should also be carefully considered; if, in our DRM example, the protected content has a restriction on the maximum number of times it can be used (a limited 'play count'), malicious software could perform a denial-of-service attack by repeatedly requesting playback until all the rights are used up.

 
Others
 
- iOS SDK : Application Settings - The Settings Bundle (part 4) - PSSliderSpecifier, PSChildPaneSpecifier
- iOS SDK : Application Settings - The Settings Bundle (part 3) - PSMultiValueSpecifier
- iOS SDK : Application Settings - The Settings Bundle (part 2) - Settings Field Types
- iOS SDK : Application Settings - The Settings Bundle (part 1)
- Ipad : Your Calendar - Calendar Options - Changing the Default Calendar
- Ipad : Your Calendar - Editing Appointments, Meeting Invitations
- BlackBerry Bold 9700 and 9650 Series : Email Set Up - BlackBerry Enterprise Server Express
- BlackBerry Bold 9700 and 9650 Series : Email Set Up - Set Up or Adjust Email Accounts from Your Computer
- BlackBerry Bold 9700 and 9650 Series : Email Set Up - Troubleshooting Your Email Accounts
- Windows Phone 7 : Building 2D Games with the XNA Framework (part 2) - AlienShooter Game Structure
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
 
Popular tags
 
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS