Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 47
Текст из файла (страница 47)
When high security privileges are needed, such as TCB orother device manufacturer capabilities, there are additional steps in thesigning process. Packaging the security-critical parts of your componentin a separate SIS file allows updates to, and new versions of, the noncritical parts to be created and distributed without requiring the overheadof device manufacturer approval for the new code and hence avoids anyadditional cost or time so expediting the deployment of urgent fixes.StructureNon-critical code and security-critical code are separated into two communicating processes to create two different memory spaces that areisolated from outside interference (see Figure 7.1).
This can be achievedwith an architecture including two user-mode processes, perhaps usingClient–Server (see page 182) for the communication between them or,where it is necessary to have code execute in kernel space, implementingthe security-critical code as a device driver which communicates withnon-critical components running in a user-space process.The process containing the security-critical components should neversimply expose a public API equivalent to an existing API requiring highsecurity privileges to access; if this were the case then any client ofthat API would have to be just as trusted as the secure agent itself,since any vulnerability in the client could be exploited by an attackerto do the same thing as they could by exploiting a vulnerability in theagent.DynamicsMalicious software may attempt to call the secure agent’s API as a wayof gaining access to protected services or data.
The interface between the18 Typicallythe device manufacturer or Symbian Signed [Morris, 2008].SECURE AGENTFigure 7.1243Structure of the Secure Agent patternsecurity-critical and non-critical components must therefore be carefullydesigned to ensure that communication across the process boundarydoes not allow unauthorized use of the privileged operations performedby the security-critical components. This undesirable consequence isknown as ‘privilege leakage’, and there are two measures which canbe implemented inside the security-critical components to avoid itoccurring:• Ensuring that only authenticated clients are allowed to invoke thesecurity-critical components, for example, by checking that the clienthas a particular SID from the protected range, mitigates the risk of244SECURITYmalicious software impersonating an authorized client and takingadvantage of the APIs exposed by the security-critical components.19• Validating the parameters passed to the security-critical componentsto ensure that they are within expected ranges mitigates the risk ofsecurity vulnerabilities caused by unexpected values whether theycome from logic errors, user input errors or deliberately exploitedsecurity vulnerabilities in an authorized client.
Such validation wouldalso include, for example, checking digital signatures on data if thedata is expected to be coming from a trusted source.Figure 7.2 shows the interaction of the non-critical and security-criticalprocesses.Figure 7.2Dynamics of the Secure Agent patternThe client process first creates a session with the secure agent whichmay cause it to be started, if it is not already running. The secure agentcan perform a one-off set of checks on the authenticity of the client atthis point or can check each service request individually. These checkscan include verification of the identity of the client process, via its SID orVID, or that it has been trusted with sufficient capabilities.When the client invokes the secure agent API to perform actions onits behalf, it can pass parameters with the request that might include, for19 The CPolicyServer class includes a method, CustomSecurityCheckL(), whichprovides a standard way of implementing such checks.SECURE AGENT245example, basic types, descriptors, and file handles.
For each action, thesecure agent is responsible for checking the validity of the parameters andany input data read from locations, such as files, provided by the client.ImplementationClientThe MMP file for the client should look something like this:TARGETTARGETTYPEUIDmyapp.exeexe0 0x200171FD // Protected-range SIDCAPABILITYNetworkServices, ReadUserData // User capabilitiesSOURCEPATHSOURCESOURCESOURCE.myapp_ui.cppmyapp_logic.cppmyapp_ipc.cppUSERINCLUDE.SYSTEMINCLUDE \epoc32\includeLIBRARYeuser.libIn this example, the client part of the application requires only usergrantable capabilities which do not require to be signed for.
Note,however, that it specifies a protected-range SID which the secure agentcan use to authenticate the client, and therefore it needs to be deliveredin a signed SIS file.Secure AgentThe MMP file for the secure agent should look something like this:TARGETTARGETTYPEUIDsecagent.exeexe0 0x200171FE // Protected-range SIDCAPABILITYAllFiles // Device manufacturer capabilitySOURCEPATHSOURCESOURCESOURCE.secagent_api.cppsecagent_validation.cppsecagent_operations.cppUSERINCLUDE.SYSTEMINCLUDE \epoc32\includeLIBRARYLIBRARYeuser.libefsrv.lib // Includes APIs requiring AllFiles246SECURITYThe secure agent is built as a separate executable. In this example,it requires a device-manufacturer-approved capability, AllFiles, so itmust either be pre-installed in the device ROM or delivered in a signedSIS file that is approved by the device manufacturer.Inter-Process CommunicationImplementing this pattern requires the introduction of a secure IPC mechanism.
Symbian OS provides a number of mechanisms which you can useto provide this, such as Publish and Subscribe (see page 114), if you needa 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 whatneeds to be communicated between the client and the secure agent.ConsequencesPositives• It is easier to concentrate review and testing on the security-criticalcode, making it more likely that any security vulnerabilities are foundbefore software has been deployed hence reducing your maintenancecosts.• 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 grantsensitive capabilities because the amount of code requiring specialapproval for signing is reduced.• It is possible to develop and quickly deploy updates to non-criticalcomponents without needing to resubmit code for signing approval.Negatives• Increased development effort is required at the design stage to dividethe functionality into suitable components and to define appropriateAPIs for communication between the non-critical and security-criticalparts.• Debugging may be more complex because of the need to trace theflow of control between multiple processes.• An additional attack surface has been added which can reduce thesecurity benefits.• The code size of your components will be increased to manage IPCand validate parameters.SECURE AGENT247• RAM usage will be increased due to the addition of an extra process(a default minimum RAM cost of 21–34 KB20 ), the increased codesize (to implement the IPC channel and the validation of the IPCmessages), and the additional objects required in your componentsand in the kernel to support the IPC.21• Creation of a separate process, marshalling of IPC, parameter validation and additional context switching between the client and thesecure agent decreases execution speed.20Example ResolvedThe Symbian OS software installer uses this pattern (see Figure 7.3) toseparate 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 functionalitythat requires TCB privileges, to write the contents of a SIS file to thefile system and update the registry of installed applications, is run as aseparate process.Figure 7.3 Structure of the Software Installer patternThe client process, which only needs the TrustedUI capability,22communicates with the SWI Server using Client–Server (see page 182)20 SeeAppendix A for more details.For instance, Client–Server (see page 182) requires objects in the client, the server andthe kernel to model both ends of a client’s session with the server.22 Available under standard Symbian Signed criteria.21248SECURITYto provide the IPC between the two processes (see Figure 7.4).
The mainpurpose of the SIS Helper component in the client is to facilitate thiscommunication. The SWI Server runs with all capabilities including TCB,DRM and AllFiles as these are needed in order to extract install binariesinto the system directories on the mobile device.SWI Server ProcessClient ProcessClientSIS HelperUI Support ServerConnect()[doesn’t already exist]:SWI ServerConnect()Install()Install()DisplayDialog()DisplayDialog()ContinueInstallation()Continuelnstallation()AccessSisData()May occur multipletimes during asingle installationin any order.Completelnstallation()CompleteInstallation()Figure 7.4 Dynamics of the Software Installer patternOther Known Uses• Malware ScannersMalware scanners are applications that include an engine to scan formalware as well as components that manage the over-the-air updateof malware signature databases and user-interface functionality suchas control panels. Only the scanning engine requires high privilegesand so it is separated from the other functionality which resides inits own process.
The scanning engine however is loaded into theSymbian OS file server process as a PXT plug-in via Buckle (seepage 252). As the file server is part of the Symbian OS TCB, DLLs itloads, such as these plug-ins, are required to have the TCB capability.SECURE AGENT249Malware scanner vendors typically package the file server scanningengine plug-in in a SIS file signed with TCB capability, and deliverother components in a separate SIS file that can be updated frequentlyand easily.
So that only a single package needs to be delivered, thescanning engine SIS file can be embedded inside the SIS file for thefull package without the need for the outer SIS file package to besigned with device manufacturer capabilities.Note that the scanning engine is responsible for making sure thatany updates done to its database are legitimate before acceptingthem; end-to-end security of such data updates is typically done byvalidating a digital signature on the update.• Symbian Debug Security ServerA further example of this pattern that includes highly trusted coderunning in the kernel is the Symbian Debug Security Server, introducedin Symbian OS v9.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
