Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 45
Текст из файла (страница 45)
This is because the processes created from an EXE aregiven the security credentials of the EXE. DLLs on the other hand,if loaded by a process, execute with the security credentials of the1 en.wikipedia.org/wiki/Defensein depth (computing)See [Heath, 2006, Section 2.4].3 If not assigned explicitly, the SID defaults to the UID3 of the executable whilst theabsence of a VID statement means that it does not have a VID.2234SECURITYprocess.
To prevent this allowing a DLL to take on security credentialsat run time, the following DLL loading rule4 is applied: ‘A processcan only load a DLL if that DLL has been trusted with at least thecapabilities that the process has’.• Data caging files – this allows important files, whatever their content, to be protected. Special top-level directories are providedon each drive that restrict access to the files within them as follows:5• /sys contains executable code and cannot be read from or writtento.• /resource allows only read access.• /private/<own SID> allows read and write access.• /private/<other SID> cannot be read from or written to.• /<other> has no restrictions.Symbian OS platform security divides components into the followingthree types:• Trusted Computing Base (TCB) [DoD, 1985] components have unrestricted access to the device resources.
They are responsible formaintaining the integrity of the device, and applying the fundamentalrules of platform security. The rest of the operating system must trustthem to behave correctly and their code has, consequently, beenvery strictly reviewed. In particular, the TCB guarantees the following:• The capabilities, SID, and VID of a process (as returned by theassociated RProcess and User functions) can be trusted by thecaller of these functions.• The capabilities, SID, and VID of executables, both EXEs andDLLs, cannot be tampered with and then executed by the Loader(part of the TCB). This includes any code loaded via RLibrary,REComSession or the RProcess APIs.• Executables on the device cannot be overridden except by legitimate6 upgrades for the executable.For more information on the services that the TCB provides see [Heath,2006].
Note too that TCB is also used to refer to the capability given4 See[Heath, 2006, Section 2.4.5].5 Unless the process is highly trusted and has been assigned a specific capability approvedby the device manufacturer.6To a limited extent this can be circumvented by using Symbian Open Signed (whatused to be known as Developer Certificates).
However, this can only be done with the enduser’s full knowledge and permission.SECURITY235to these components, such as the kernel and file server and, on opendevices, the software installer.• Trusted Computing Environment (TCE) servers, beyond the TCB,which are granted orthogonal restricted system capabilities. Thisincludes servers providing sockets, telephony, certificate management, database access, and windowing services.• Everything else.To build secure software on top of Symbian OS it is particularly importantto keep the following principles in mind:• Economy of mechanism [Saltzer and Schroeder, 1975] – this is thepractice of minimizing the size of highly trusted code by separating itfrom code that doesn’t require the same level of trust. Such separationenables closer scrutiny and analysis of the security-critical code,increasing confidence that vulnerabilities will not be found after thesoftware has been deployed.• Complete mediation [Saltzer and Schroeder, 1975] – access to aprotected resource must always be checked and any temptation tocache decisions for execution performance reasons must be examinedskeptically.• Open design [Saltzer and Schroeder, 1975] – security should notdepend on keeping mechanisms secret as they are difficult to maintainthis way and provide little defense once they’ve been publicized.
Youalso forego the benefits of others reviewing your design.• Least privilege [Saltzer and Schroeder, 1975] – this requires that eachprocess executes with the least number of capabilities possible so thatit only accesses such information and resources as are necessary forits legitimate purpose. This minimizes the damage that can result fromsecurity vulnerability in a single component.• Privilege leakage – when a process is trusted with a privilege it isexpected to guard the access it is granted by having the privilege. Thismeans that you should carefully consider whether to allow a processto perform an action on behalf of a process that uses a privilege unlessit has the same privilege itself.Having developed a component based on Symbian OS that makesuse of specific capabilities you may need to distribute your softwarefor installation on other people’s devices.
Unfortunately, it’s not alwayspossible to simply put it up on a website somewhere and have peopledownload copies to their devices. If your component requires the useof a capability, for whatever reason, then you may be able to rely onthe user to grant blanket permission to the application at installationtime or ‘single-shot’ permission at run time. However, if this is not the236SECURITYcase then your component must be signed: a process that associatesa tamper-proof digital certificate with the component that identifies itsorigin and allows the software installer to judge whether or not thecomponent should be allowed to install with the security credentials itsays it needs.Executables need to be signed so that stakeholders other than theoriginal developer can judge whether or not they should trust them.
Forinstance, the end user wants to know that their personal data isn’t goingto be stolen; a content provider wants to prevent unauthorized copiesof their music being made, and Symbian and the device manufacturerwant to protect their reputation for providing reliable devices. By signinga component with a specific capability, you promise to maintain theintegrity of the parts of the device to which the capability gives yourcomponent access.Not all capabilities are equal and the cost of assigning a capabilityto a component varies considerably. Consider the four main types ofcapability given below in order of increasing sensitivity:• User capabilities are designed to be meaningful to end users who maybe allowed7 to grant blanket or single-shot permission for executablesto use these capabilities even if they haven’t been signed.• System capabilities protect system services, device settings, and somehardware features.
Use of these capabilities requires executablesto have been signed. The signing process for these capabilities iscurrently free and can be done locally for testing or for personal use.For commercial use, there are some moderate costs involved andsigning cannot be done locally.• Restricted system capabilities protect file system, communications,and multimedia device services. Use of these capabilities also requirescode to have been signed. The signing process for these capabilitiesfor any use currently requires a moderate cost and signing cannot bedone locally.• Device-manufacturer-approved capabilities are TCB and system capabilities that protect the most sensitive system services.
Use of thesecapabilities requires a device manufacturer to have given permissionfor the associated application or service to be signed for use on theirdevices.Each additional capability that is required may require one or moredeclarative statements to be filled out or extra testing during the signing process. The more sensitive a capability is, the more likely theyare to occur. For further details on how Symbian Signed works see[Morris, 2008].7 Dependingon the security policy for a particular device.SECURITY237In summary, components that use the more sensitive capabilities meanadditional financial and development costs for the component provider.This is especially important when providing an extension point for whichanother vendor is intended to supply the plug-ins.
For instance, if youwere to require plug-ins to have the TCB capability it would meanthat most plug-in providers would not be able to target your extensionpoint as they’d not be able to obtain permission for the capabilitiesrequired.Another point to remember about capabilities is that they should onlybe assigned to a process if they are needed to access a specific API.8Capabilities should not be assigned just to impose additional restrictionson DLLs loaded into the process.
For instance, a device manufacturermight be tempted to assign a process the AllFiles capability and soprevent third-party DLLs from being loaded. Whilst this would appearto work, in certain circumstances it would be possible to circumventthe restriction if the process doesn’t actually call an API which checksAllFiles capability. This is because capabilities are not a generalmeasure of trustworthiness. Capabilities were designed to control accessto APIs; when a binary is signed with a certain set of capabilities itsimply means that it is permitted to access those APIs.
Capabilities aren’tintended for the purpose of saying ’this code is more trustworthy thanthat code‘, they are designed to say ’this code needs to access certainAPIs and that code doesn’t’.9 As an example, if an executable is assignedcapability X, which it does not need for any API call, then it could be‘upgraded’ to a version that isn’t assigned capability X by using SymbianOpen Signed.10 This ‘upgraded’ version of your component would thenexecute without any problems but at a lower level of trust which mightbe enough to allow the malicious developer to be able to install theirplug-in into your process and access all its memory.In most situations, this restriction on being able to assign capabilitiesisn’t a problem because if a process handles sensitive information and sowants to ensure that loaded DLLs can legitimately have access to the datathen the process has usually obtained the sensitive data by calling theAPI of the appropriate service.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
