Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 52
Текст из файла (страница 52)
malware) or unintentional.Such actions might include unauthorized access to hardware, attemptsto read or write restricted data, etc.This section gives you an introduction to the way that platform securityis implemented, with a particular focus on ensuring that you know howto update your applications to conform to and work within the platformsecurity-enabled Symbian OS environment. Knowing how to do this willallow you to successfully go through the Symbian Signed process andrelease your application.CapabilitiesPlatform Security provides protection by ensuring that only trusted applications can use certain functionality within Symbian OS.
It introduces theidea of capabilities, which protect APIs within Symbian OS.Not all of the APIs in the Symbian OS are capability-protected – infact, only about 40 % of Symbian OS APIs fall within this category; allother APIs still have unrestricted access. Of those APIs that are protected,many are used to access the low-level aspects on Symbian OS, so it isunlikely that you will need to use them.If your application needs to use any of the APIs that are protected bya capability, it must request use of the capability.
This is called authorizing your code. Once the authorization is obtained, the application isauthorized and can use the protected functionality.The Symbian Signed programme is your route to authorizing andreleasing your applications before the user receives them so we’ll take aquick look at this now, with more detail in Section 9.5.HOW DOES PLATFORM SECURITY WORK?265Authorizing via Symbian SignedThere are a variety of capabilities (see Section 9.7) that are used to protectfunctionality within Symbian OS.
To ease the process of authorizingapplications, Symbian Signed groups them together into two sets forverification – basic and extended.• The basic capabilities protect the APIs that: access confidential userdata; provide data about the user’s environment; and access network services (both locally and remotely). Being authorized for thebasic capabilities ensures that users of your application are authorized for access to services and to data (for example, to send textmessages, make Bluetooth connections to other phones and accessuser-confidential data such as contact information) without the userbeing asked explicitly for permission.• The extended capabilities protect the APIs that provide lower-levelaccess to system functions, such as changing the network configuration, in addition to the basic capabilities.
Applications requiringauthorization for the extended set via Symbian Signed have toundergo additional testing as these APIs require what is known as‘phone-manufacturer approval’.Within the extended set are some particularly sensitive capabilities, designated ‘Phone-Manufacturer Approved’, which include DRM,DiskAccess, NetworkControl and AllFiles. These capabilities controlaccess to areas of the phone or content on the device that manufacturers may want to restrict, and therefore Symbian Signed has additionalcriteria to be satisfied if your application needs any of these capabilities.If you decide to follow the Symbian Signed route, Section 9.5 containsmore details of what you need to do.Authorizing without using Symbian SignedSometimes you don’t actually need to authorize your code in advance touse the capability-protected functionality.The Symbian Signed process does a good job in protecting the phonefrom errant applications and providing a number of routes to market,but there are times when getting an application signed may not beappropriate.
In this situation, you can take advantage of the UnsignedSandboxed capabilities set. The unsigned-sandboxed capabilities consistof all functionality that doesn’t require any capabilities and all capabilitydependent functionality for which access may be granted by the user.If the application is not signed, Symbian OS can ask the phone userdirectly when the application is installed if they are prepared to authorizethe unsigned-sandboxed capabilities that the application declares in its266PLATFORM SECURITY AND PUBLISHING APPLICATIONSproject definition (MMP) file (this is called a blanket grant ). An unsignedsandboxed application only has access to a subset of APIs.
If yourapplication only needs to access functionality in this set there is no needto submit it to Symbian Signed. That said, a phone manufacturer may stillrequire you to ‘sign’ the application with a certificate that you can createusing tools in the SDK.If you prefer your application to be authorized and that the phoneuser never has to be asked for authorization to perform operations, thenthe application should be Symbian Signed.
It is also worth noting that,depending on how you intend to distribute or sell your application, somechannels may require an application to be Symbian Signed before theyeven consider it for distribution via their sales channels.One-shot GrantsIt’s not possible for users to blanket-grant all capabilities – only a SymbianSigned application can have this authorization.
Instead, if you needlimited use of a particular capability (perhaps to send an SMS), you canuse selected APIs on a ‘one-shot grant’. To achieve this, because theaccess is being granted as a one-off, special case, you mustn’t requestthese capabilities in your project definition file like other capabilities(otherwise installation will fail as they cannot be authorized by theuser) – just ensure they are excluded.If you subsequently want your application to be Symbian Signed, withcapabilities you require being given a blanket grant, you only need to addthe required capability to your project definition file and your applicationcode can remain unchanged.9.3 How Do I Support Platform Security?In order to support the platform security architecture, a number of APIswere added, amended or deleted in Symbian OS v9.
Information aboutthese changes is available in the SDKs. If any of the APIs that you usein applications running under versions of Symbian OS before v9 areaffected, you need to make the appropriate changes.Project Definition FilesThe capabilities that an application needs are defined at build time in theproject’s definition file. The CAPABILITY keyword is followed by a listof the capabilities that the executable requires.TARGETCAPABILITYexample.dllLocalServices ReadUserDataHOW DO I SUPPORT PLATFORM SECURITY?267A list of capabilities can be found in Section 9.7.You can work out what capabilities need to be specified by checking the documentation – this shows which API calls are protected bywhich capabilities – and specifying all these capabilities in the MMP file.(You can also use the emulator to see if you’ve omitted any requiredcapabilities, see Chapter 10.)Instead of specifying capabilities in a list, the special capability nameNONE can be used.
This is the default value if the CAPABILITY keywordis not found in the MMP file.There are a number of APIs whose capabilities do not necessarily haveto be specified in the MMP file. If the relevant capability is not specified,authorization may still be granted on a one-shot basis. (This appliesto both signed and unsigned-sandboxed applications, as discussed inSection 9.2.)Secure IDsIn Symbian OS v9, each executable has a Secure ID (SID) which uniquelyidentifies it. SIDs are a specialized use of the UID3 value, which isspecified in your application’s MMP file with the keyword UID.
The SIDvalue, unless explicitly specified otherwise by the SECUREID keywordin the MMP file, defaults to the same value as the application’s UID3. Toavoid confusion, a SECUREID should not be specified in the application’sMMP file. The SID value is not relevant for DLLs since the SID of a processis always that of its EXE.A SID can be requested in the form of a UID from the Symbian Signedportal, www.symbiansigned.com. This is an automated process and theUIDs are issued instantly.
Note that the UIDs are divided into two rangesand only values from the protected range are valid SIDs. UIDs from theunprotected range are often used during development and testing. TheSymbian OS software installation system checks that a file is using a UIDfrom the protected range. If not, your application won’t install.Data CagingAnother feature of platform security is data caging. This means that eachapplication, when installed, has its own private directory on the phonethat is accessible only by a process with either the same UID as theapplication or with certain privileged capabilities. For example, yourapplication cannot access configuration files of another application thatthe user has installed.Each data-caged directory resides under the \private directory onthe phone and is named according to the SID of the main application:\private\<application SID>\...268PLATFORM SECURITY AND PUBLISHING APPLICATIONSThe private directory can be created on any writable drive, howeveronly certain drives can be described as secure.
A secure drive must havemedia that is not removable and cannot be accessed by an external ‘host’computer using a mass-storage file system connected via USB. For drivesthat do not satisfy these criteria, the data stored in the secure areas caneasily be accessed by the computer system connected to them.Other directories in the file system are also restricted by Symbian OS,regardless of drive:• \resource\. . . contains resource files for installed applications.Resource files for an application can only be written to this directory atinstallation time by the Symbian OS software installer. No capabilitiesare required to read the resource files stored in this directory.• \sys\.
. . contains system files and installed binaries. Again thesebinaries can be written to only by the software installer. If an application is installed on media that can be accessed by an externalcomputer then the binary files are protected by a hash checksum.Each time the binaries are loaded, the hash is checked to ensure thebinary has not been modified in any way. If tampered with, a binaryis not loaded.Other areas of the file system, from the root directory upwards, areconsidered public and can be accessed with no capabilities.9.4 Preparing an Application for DistributionHaving discussed Platform Security, we need to see what effect it has ondistributing applications.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
