Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 46
Текст из файла (страница 46)
For instance, if a process handles sensitivedevice settings then it might have obtained the data originally from theCentral Repository which checked it as having the ReadDeviceDatacapability.When two processes with different levels of trust interact they bothneed to be wary of what information they send outside of their process,or zone of trust. For instance, Digital Rights Management (DRM)11 data8 Whether the process could achieve the same result by calling a different API whichdoesn’t require the capability in question is another issue.9 The principle of least privilege.10Such signatures are tied to specific devices but for this attack that’s more than enough.11 DRM refers to technologies used by publishers and copyright holders to control accessto and usage of digital media.238SECURITYshould not be passed outside a process assigned the DRM capabilityunless the recipient also has the DRM capability.
Similarly you shoulddesign a process to take care when handling received data. As an example,a DRM process should not only validate all such data, in case it is corrupt,but it should also take into account the level of trust placed by the systemin the originator of the data. If a non-DRM process is always allowed tostart the playback of DRM material then a malicious application, withouteven seeing any DRM data, could cause material with a fixed number ofuses12 to become inaccessible.Now that we’ve given you an introduction to how security works onSymbian OS, we can move onto the patterns that you can use to build ontop of this foundation. Secure Agent (see page 240) builds on the conceptof processes as zones of trust and describes how to put into practice the‘economy of mechanism’ principle when you have to perform one ormore actions requiring the most sensitive capabilities.The remainder of this chapter describes how to support plug-ins to aflexible architecture but without sacrificing security in doing so.
Architectural extensibility is a common requirement as it allows your softwareto be easily upgraded or customized in future. However, by using plugins, you introduce new attack surfaces by which malicious software canattack your components. Hence extensibility needs to be balanced withmeasures to restrict the damage that might be caused by accidental ormalicious actions by the plug-ins. In general, the more secure a frameworkneeds to be, the more restrictions it has to place on who can provide aplug-in for it.
Without careful consideration of the architecture and designof a solution, it is all too easy to make the restrictions too harsh and unnecessarily limit who can provide plug-ins for your application or service.The following list summarizes the characteristics of the remaining patterns in this chapter and how they solve this trade-off between flexibilityand security:• Buckle (see page 252):• There is a low degree of complexity.• There are no limitations on interaction between the frameworkand a plug-in.• Plug-ins are not isolated from the framework or each other.• The capabilities of a plug-in must match those of the framework.• No additional processes are required.12Such material can only be played a finite number of times before the license expires;for instance, you may be able to play a game only three times before you must pay for it.SECURITY239• Quarantine (see page 260):• There is a medium degree of complexity.• Interaction between the framework and a plug-in is limited toone-off communication at initialization.• Plug-ins are isolated from the framework and each other.• The capabilities of a plug-in are independent of those of theframework.• An additional process is required per plug-in.• Cradle (see page 273):• There is a high degree of complexity.• There are no limitations on interaction between the frameworkand a plug-in.• Plug-ins are isolated from the framework, and from each other ifrequired.• The capabilities of a plug-in are independent of the framework butthere are a few restrictions.• Additional processes are required.Whilst reading the following patterns please remember that at no pointshould any of them be used to breach the security of the device by simplyremoving an inconvenient security restriction.
By doing so you put at riskthe security assets of the device, which includes the end user’s privatedata, and may incur costs on the user’s behalf. Most of the patterns in thischapter introduce additional process boundaries as part of their solutionso that there exist two or more components executing at different levelsof trust.
In such cases, you need to keep in mind what each process istrusted to do and restrict its functionality to just that and no more. Forinstance, a framework that handles DRM data and runs plug-ins in aseparate sandbox that isn’t trusted with the DRM capability should neverpass DRM data to the plug-ins. Since there are no technical issues thatprevent this, once the framework has got hold of the DRM data, youneed to be careful in your designs to prevent this happening. Otherwisethe framework would be in breach of the conditions of holding theDRM capability and should not be surprised if a plug-in is created thatsuccessfully copies the DRM data that it illicitly handles.240SECURITYSecure AgentIntentMinimize security risks by separating out security-critical code into aseparate process from non-critical code.AKAIsolate Highly Trusted CodeProblemContextYou are developing an application or service which includes functionalityrequiring high security privileges13 together with a similar or greater proportion of functionality which can run with lesser or no security privileges.Summary• It is more difficult to find and fix security vulnerabilities in componentswhich include both security-critical and other code (‘economy ofmechanism’).• Developers of components which require high security privilegesshould minimize any liability they may be exposed to due to errors indesign or implementation (‘least privilege’).• You wish to make it as easy as possible to create and distribute updatesto your code.• When using any security privilege, but especially the device-manufacturer-approved capabilities, you are required to ensure that theprivileges are not leaked and unauthorized software cannot use them.DescriptionThe most straightforward architecture for an application or service may beto structure it as a single Symbian OS process or device driver; howeverif some of its functions require device manufacturer capabilities such asTCB, AllFiles or DRM there are likely to be longer-term drawbacks inhaving the highly trusted parts of your component executing in the sameprocess 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 securityvulnerabilities has to consider all of the code as equally likely to be a13 Using APIs which require capabilities granted by the device manufacturer or runningin the kernel.SECURE AGENT241potential source of a vulnerability.14 When all of the code is running withthe same set of capabilities, a vulnerability anywhere in the code couldpotentially be exploited to use the most sensitive APIs and data accessibleby the process.
Also, when all the code is packaged for certification andsigning as a single component, changes anywhere in the code may leadto the entire component needing to be recertified as requiring the devicemanufacturer capabilities and not just the highly privileged code. Thisis true even if the code is separated out into different DLLs since theDLL loading rule would require them to have any device manufacturercapability that the process that loads them does.ExampleThe Symbian OS software installer (SWI) is one of the most critical partsof the platform security architecture.
It has, in effect, the highest levelof security privileges15 and therefore needs to be trusted at the highestlevel; it is part of the Trusted Computing Base (TCB) [DoD, 1985] andmalicious functionality injected into the TCB can do anything it wants.At the same time, the software install subsystem covers a lot offunctionality that should not be security-critical; it is desirable for clientswithout device manufacturer capabilities to be able to invoke the softwareinstaller and supply a package using various communication and storagemechanisms; it is only necessary that the package being installed correctlypasses security checks. The client is also likely to make use of DLLs whichare not granted the TCB capability, and thus could not be linked in to aprocess which has been assigned that capability. This is because almostall the DLLs provided by Symbian OS have all capabilities except forTCB, precisely so that they can be widely used but do not have to beaudited for use within the TCB.SolutionDivide your software component into two or more components, withat least one component containing code which is security-critical, andone or more components containing code which is not security-critical.Security-critical code should include both code which requires highsecurity privileges to execute16 and code which checks the correctness of input data affecting security-related operations.17 For example,non-critical code could include user-interface components and application logic which only requires access to the application’s own privatedata.14Because all the code within a process has access to all the memory used by that process.instance, it is able to replace or eclipse any executable on the device.16 For example, accessing protected files.17 Such as whether an update to a database was generated by an authorized originator.15 For242SECURITYDividing your software component into two or more componentswhich execute as separate processes allows each component to be givenonly the capabilities which it needs to perform the subset of functionalitywhich it implements.
By introducing additional processes, each withtheir own isolated memory spaces, you minimize the damage that canresult from a security vulnerability in one component (‘principle of leastprivilege’).Such separation enables closer scrutiny and analysis of the securitycritical code, increasing confidence that vulnerabilities will not be foundafter the software has been deployed. This practice of minimizing the sizeof highly trusted code is a well-established security principle (‘economyof mechanism’).If your component is distributed as an installable package (a SISfile), it will need to be signed by a trusted authority18 to be grantedcapabilities.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
