Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 48
Текст из файла (страница 48)
The low-level operations of the debugger (readingand writing registers and memory belonging to the debugger process,suspending and resuming threads, etc.) are implemented in a LogicalDevice Driver (LDD) called the Debug Driver, which represents theSecure Agent as described in this pattern. The device driver providesthe low-level functions to a process running in user mode called theDebug Security Server. When started, the Debug Driver checks theSID of the client to ensure it is the Debug Security Server so that onlythis authorized process can access it.
The Debug Security Server inturn checks the SID of its clients to ensure that it only provides debugservices to authorized debuggers. The Debug Security Server uses asecurity policy based on access tokens and process capabilities toensure that a debugger client is only able to access those processes itis authorized for.Variants and Extensions• Separating Security-Enforcing Code from Highly Privileged CodeIn some ways, the desire to group together security-critical code, suchas the TCB, to allow in-depth security evaluation is in tension with thedesire to isolate code that requires high security privileges to performits function according to the principle of least privilege.
To resolve thistension it may be helpful to consider separating a software componentinto three subsets (see Figure 7.5).It is possible to extend the Secure Agent pattern to architect anapplication or service as three communicating processes. The benefitsof separately considering the security characteristics of the trustedcode (including both security-enforcing and highly privileged code)are maximized by being able to exclude the non-critical code from250SECURITYLess PrivilegedNon-CriticalProcessSecurityEnforcingProcessHighlyPrivilegedProcessTrustedFigure 7.5 Separating security-enforcing code from highly privileged code structuresecurity review.
The benefits of the ‘least privilege’ principle aremaximized by separating out the security-enforcing code that doesnot need high security privileges from the code that must be highlyprivileged to perform its function.Factoring the component into three processes, however, magnifiesall of the negative consequences listed above so this more complexapproach is best reserved for situations where security is of paramountimportance. Something analogous to this can be seen in the SymbianOS platform security architecture [Heath, 2006], where the TCBis limited to that functionality which absolutely has to run withthe highest privileges and a lot of security-enforcing functionalityis provided by system servers in the TCE, which run with only thespecific system capabilities they need.• Open-Access Secure AgentWhere the secure agent can safely provide services to any client, theauthentication step can be omitted.
One example of this could bea service which allows unprivileged clients to initiate playback ofDRM-protected content without giving the client any access to theprotected data itself. The secure agent still needs to include validationchecks on the parameters and other data passed to it to ensure thatmalicious software cannot exploit any vulnerabilities resulting fromprocessing of out-of-range or other unexpected data.
The securityimplications of such a design should also be carefully considered;if, in our DRM example, the protected content has a restrictionon the maximum number of times it can be used (a limited ‘playcount’), malicious software could perform a denial-of-service attackby repeatedly requesting playback until all the rights are used up.SECURE AGENT251References• Client–Server (see page 182) can be used to implement the IPCrequired between the secure agent and the client processes.• Protected System [Blakley, Heath et al., 2004] provides some reference monitor or enclave that owns resources and therefore must bebypassed to get access.
The Secure Agent described here can be seenas an enclave in the Protected System pattern.• Trusted Proxy [Kienzle et al., 2002] describes a component that actson behalf of a client to perform specific actions requiring moreprivileges than the client possesses. It provides a safe interface byconstraining access to the protected resources, limiting the operationsthat can be performed, or limiting the client’s view to a subset of thedata. The Secure Agent described here is an example of this.252SECURITYBuckleIntentLoad DLL plug-ins, which match your level of trust, into your own processto increase the flexibility of your architecture without compromisingsecurity.AKANone knownProblemContextYou need to provide a simple-to-use but secure extension point in yourcomponent to easily allow future upgrades or customization.Summary• Architectural extensibility has to be provided.• The potential damage caused by plug-ins needs to be limited byminimizing the capabilities with which they execute (principle ofleast privilege).DescriptionA plug-in is a component loaded into a framework at run time so as toprovide a certain, usually very specific, function.
Frameworks supportplug-ins for many reasons which include:• enabling yourself or other vendors to provide additional functionalitythat extends an application or service• easing porting of the application or service to different devices.One possible way to achieve this is by having a configuration file thatallows new settings to be specified after a component has been released.However, this is normally quite restrictive and so a mechanism by whichadditional code can be plugged in is needed.This problem is seen by all types of developer whether they’re a devicecreator or a third-party application developer.ExampleIf you are creating a service for a mobile phone, then it’s unlikely that yourcode will include a full graphical UI.
Despite this, there are occasionsBUCKLE253where you still need to be able to display notifications and prompts tothe end user. For instance, when the Messaging subsystem detects thatan SMS has been received, it needs to be able to alert the user with a‘Message received’ notification.To help fulfill this requirement, Symbian OS provides a NotificationServer that exposes the RNotifier API.
However, whilst this works fora number of use cases, it doesn’t support:• UI-specific dialogs that reflect the look and feel of a device as specifiedby the manufacturer or operator• application-specific dialogs provided by third-party developers.Clearly, to support the above, the Notification Server needs to beextensible. However, to allow untrusted code to provide dialog plugins would mean that a malicious attacker could deliberately attack theNotification Server by creating a high-priority notifier which monopolizesthe screen. This would prevents any lower-priority notifiers from beingactivated and potentially make the device unusable: the extension pointneeds to be protected from being misused.SolutionUse the ECom service23 to provide the general extension point functionality of selecting and loading plug-ins as DLLs that expose the plug-ininterface specified by your framework.
This forces plug-ins to have thesame capabilities as the framework itself.The name of the pattern reflects this purpose: buckles are about joiningtwo objects together (pieces from two different buckles can’t be connectedtogether) and they’re used in seat belts to keep people secure.Note that this is the most frequently used of all the secure plug-inpatterns.StructureThis pattern has the simple structure shown in Figure 7.6.Once each plug-in is loaded, it resides within the framework processand can be used exactly as if it had been statically linked to duringdevelopment. However this structure has significant security implications:• A plug-in must satisfy the DLL loading rule or it cannot be loadedinto the framework process. This rule states that the plug-in DLL musthave the same, or a superset of, the capabilities of the loading process.23See [Harrison and Shackman, 2007, Section 19.3] for details about ECom.254SECURITYFigure 7.6Structure of the Buckle pattern• You have chosen to welcome the plug-in into your process andhence do not get any of the benefits of memory isolation offered byexecuting in a different process.
It means that a plug-in has access toany memory used by the framework since Symbian OS only enforcesmemory isolation between processes. It also means that once loadedno further security checks can be made by the framework on aplug-in.24• Calls by a plug-in to other processes can be authenticated as normal.However, these checks are made on the credentials of the frameworkprocess and not anything specified by the plug-in provider.• It is not possible to authenticate a plug-in by an SID or VID as theseare properties of a process at run time and not of code in a DLL.As far as security is concerned everything hinges on the capabilitiesyou, as the framework provider, assign to the framework process. Whenyou assign these capabilities you should follow these guidelines:• Assign the minimum set of capabilities needed (principle of leastprivilege).• Assign the capabilities required by the framework to meet the securitypolicies imposed by the APIs it calls.• Assign the capabilities required by a plug-in to meet the securitypolicies imposed by the APIs it calls.• Do not assign a capability solely to impose an additional restrictionon who can provide a plug-in to your framework because whilstthis may appear to work there are situations in which it can be subverted.In the advent of someone trying to spoof the framework this structuredoes not prevent a plug-in from being loaded.
Assuming the plug-in canbe loaded then it’ll be run with the capabilities that the loading processhas been able to obtain. The platform security architecture of Symbian OS24 The plug-in can access and change any stack memory, including return values from afunction checking a security policy.BUCKLE255allows us to assume that the loading process has obtained its capabilitieslegitimately. Hence it can only run the plug-in successfully if it has beentrusted with the capabilities used by the plug-in when calling APIs andno advantage is gained by the spoof framework.DynamicsIt is when a plug-in is loaded that the security check on the plug-in occurs.A plug-in is only successfully loaded if the plug-in’s DLL has at least eachof the capabilities assigned to the framework EXE. Once loaded, a plug-inis within the process’ isolation boundary and will potentially have accessto all memory and resources of the framework process.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
