symba (779893), страница 8
Текст из файла (страница 8)
The platformsecurity model prevents applications from gaining unauthorized accessto Symbian OS services, the hardware, or system and user data.The Symbian OS platform security architecture is based on a trustmodel. One of the most fundamental concepts in platform security isPLATFORM SECURITY17the definition of the unit of trust. Symbian OS defines a process as thesmallest unit of trust. The phone hardware raises a processor fault if accessis made in a process to an address not in the virtual address space of thatparticular process.
Symbian OS can trust that a process cannot directlyaccess any other virtual address space, because the hardware preventsit. Thus hardware-assisted protection provides the basis of the softwaresecurity model.Platform security prevents software running on Symbian OS from actingin an unacceptable way, intentionally (by malware) or unintentionally. Itis a system-wide concept which has an impact on all developers, whetherthey work on applications, middleware or device drivers.On Symbian OS, platform security controls what a process can do andrestricts its activities to those for which it has the appropriate privileges.The system is divided into tiers of trust and these tiers combine themselvesin pairs to form the device’s system software and other software that runson top of the underlying platform, as follows:• Trusted Computing Base (TCB) – the most trusted part of SymbianOS.
Among other things, it ensures the proper operation of platformsecurity by controlling the lowest level of the security mechanism. Itincludes the operating system kernel, kernel-side device drivers, thefile server, the native software installer and the memory managementunit (MMU). Only a few user libraries which are needed by the fileserver are included in the TCB. Any code that belongs to the TCB isreviewed very carefully.• Trusted Computing Environment (TCE) – trusted software includingthe rest of Symbian OS and some provided by other suppliers, such asthe UI platform provider and the phone manufacturer.
Functionalityexposed by the TCE is usually implemented in server processes thathave only the required privileges. This restricts access to low-leveloperations and prevents misuse by other processes.Application software is not usually part of the TCE. In order toutilize system services, it accesses the APIs provided by servers in theTCE. For example, a music player application would not normallycommunicate directly with the hardware and therefore does notneed the same privilege as parts of the multimedia framework andaudio device drivers. The application uses the APIs provided by themultimedia framework to access services within the TCE. Privilegesfor audio hardware access are typically enforced across the audioserver process boundary. (The audio server hosts DevSound,1 seeFigure 2.4.) Alternatively a device manufacturer may prefer to enforcethem at the driver process boundary.1 DevSoundis part of the Media Device Framework, described in Section 2.4.2.18MULTIMEDIA ARCHITECTURE• Other trusted (signed) software – Most application software lies outsideof the TCE tier, however this software often needs certain privilegesto use the services that the TCE provides.
It is important that anyapplication requesting a service be considered trustworthy before therequest is granted. A measure of this trust is that the software has beensigned by a trusted certification authority to grant it the privileges itneeds. More information about signing can be found on the SymbianSigned portal, www.symbiansigned.com.• Other software – unsigned or self-signed, and therefore untrusted,software.
A user can install software to his Symbian smartphone thatis untrusted (meaning that it is not signed or, more commonly, thatit is ‘self-signed’). This means that it has not been signed by one ofSymbian’s trusted authorities so the identity of the author has not beenverified: it does not necessarily mean that the software is maliciousor worthless. The software can be installed and run on the phonebut cannot perform any actions which require security privileges,except where those privileges are grantable by the user.
An exampleof software that could be self-signed is a Solitaire game that does notperform any actions that access sensitive user data or system-criticaldata or services.Third PartyApplicationsSimpleGameMediaPlayerUI PlatformFrameworkExtensionsUI FrameworkApplicationFrameworkVoIPClientUI PlatformServicesTaskManagerUI StyleJavaGameMIDP 2.0CLDC 1.1UIToolkitJVMApplicationServicesPIMMessagingData SyncSWInstallOS ServicesGenericServicesCommsServicesGraphicsServicesMultimediaServicesBase ServicesLow levelLibrariesFileserverKernel and HardwareIntegrationKernelServicesDeviceDriversTCB – all capabilitiesTCE – capabilities necessaryfor functionUntrusted software –capabilities granted by userJava applications –separate signing schemeFigure 2.1Tiers of trustJavaConnectivityServicesOther trusted software –capabilities granted by signingPLATFORM SECURITY19Figure 2.1 shows the components of a Symbian OS smartphoneplatform and the four tiers of trust: the TCB, the TCE, other trustedsoftware and the rest of the Symbian OS platform.
Note that the applications shown are chosen as typical examples of applications that do anddon’t require signing – some games and media players may use sensitivecapabilities and would therefore need to be signed.2.2.1 Capabilities as PrivilegesPlatform security is built around the use of capabilities to represent accessprivileges. A capability is a statement of trust. Every executable (EXEsand DLLs) is tagged with some capabilities at build time and at run time.Every process is granted a set of capabilities.
The capabilities are assignedbased on which APIs a process needs and is authorized to use.The kernel holds a list of capabilities for every running process and aprocess may ask the kernel to check the capabilities of another processbefore deciding whether to carry out a service on its behalf. For installablesoftware, the installer acts as a gatekeeper and validates that the programis authorized to use the capabilities it was built with.
The authorizationcan be a digital signature or user permission. There are four families ofcapabilities:• User-grantable capabilities relate to security that the user can comprehend and make a choice about; for example, a user can decidewhether to install software that accesses his personal data or not.• System capabilities allow a process to access sensitive operations.They protect system services, device settings and some hardwarefeatures.
Installable software which needs system capabilities shouldbe granted by a trusted certification authority such as Symbian Signed.• Restricted capabilities require a higher level of trust and protect, forexample, the file system, communications and multimedia deviceservices. They are restricted because of the potential to interfere withcore functions of the device, such as making calls or playing tonesto alert the user. The publisher of installable software that requiresrestricted capabilities must be identified to Symbian Signed via aPublisher ID.• Device manufacturer capabilities (TCB, AllFiles and DRM) are themost sensitive.
They either protect the integrity of the platform securitysystem or could expose the device manufacturer to legal liabilities.For this reason, capabilities in this group may only be granted withthe approval of the device manufacturer.In addition to protecting access to critical services on the phone,platform security also provides a data caging mechanism, which allows20MULTIMEDIA ARCHITECTUREan application to store data in a folder reserved for it that can not beaccessed by other applications (except for applications trusted with theAllFiles capability).2.2.2 Implications for Multimedia DevelopersThe majority of multimedia application developers only need usergrantable capabilities and their applications don’t need to go throughan official signing process – that is they can be self-signed.
For example,to read media files from any public directory on the device ReadUserData is required and to modify a playlist requires WriteUserData.These are likely to be the only capabilities required for a playback application. It can even be possible to request the system to play contentprotected by digital rights management, without the application requiringthe DRM capability.2 In addition, any application that wants to recordmultimedia content requires the UserEnvironment capability, whichis also user-grantable.However, the situation is very different for developers attempting toextend the multimedia framework via ECOM plug-ins.
As we describedin Section 2.1, an ECOM plug-in is a DLL. Platform security imposes thefollowing rule: a process can only load a DLL if that DLL has been trustedwith at least the capabilities that the process has.For example, if an application is trusted with the DRM capability, thenany DLL loaded by that application would execute with that capability(since it is the application process that is trusted and the DLL runswithin it). Therefore the DLL must also be trusted with DRM otherwise itwould represent a security hole that could allow a developer of untrustedsoftware to access the unencrypted contents of protected files, simply bybeing loaded into a more trusted process. The same argument applies toother capabilities, not just those relating to multimedia, so plug-ins forany frameworks that could be used by a number of applications need tobe trusted with a broad set of capabilities (in practice, often all but theTCB capability).Plug-in developers should be aware that the rule does not work inreverse.
A DLL trusted with a large number of capabilities may beloaded by an application with none at all. However, in that situation,the plug-in code executes with no capabilities, since the process is nottrusted with any. The DLL needs to be able to handle the fact thatany API calls it makes that require capabilities may fail, typically withKErrPermissionDenied.2 Thiswould involve requesting another process which does have the capability to playthe content for you.
S60 provides the CDrmPlayerUtility for this purpose from 3rdEdition onwards. The class is defined in drmaudiosampleplayer.h and you need tolink against drmaudioplayutility.lib to use it. For more information, see the relevantSDK documentation. Section 2.3 discusses DRM on Symbian OS in more detail.THE CONTENT ACCESS FRAMEWORK21More information about platform security can be found in Symbian OSPlatform Security by Craig Heath et al.
(2006) and in the Symbian Developer Library documentation found online at developer.symbian.com orin your chosen SDK.2.3 The Content Access FrameworkOne of the key benefits of platform security for content owners anddistributors is the provision of a solid foundation for Digital RightsManagement (DRM) systems.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
