Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 44
Текст из файла (страница 44)
If you call an API function in yourprocess that requires a capability not specified in the MMP file, it willreturn KErrPermissionDenied (-46).Not all API functions require a capability to use them. In fact, about60% of the APIs are not associated with a capability at all. If your programconsists of calls entirely in this set, then you do not need to worry aboutplatform security, and you can run your software without going throughthe Symbian Signed process. Capabilities represent the APIs that aresensitive enough to be managed by platform security, such as those thatdirectly access system or user data, or the phone hardware.Capabilities fall into the following categories, based on just howsensitive they are:•basic capabilities;•extended capabilities;•phone manufacturer capabilities.For the last two categories, in addition to needing these capabilities inyour MMP file, you must also have your application Symbian Signed toprove you are allowed to use these capabilities.
Otherwise, the softwarecannot be installed. Software requiring just basic capabilities, or none atall, does not necessarily need to be signed. To explain this further, let’slook at the three capability categories in more detail.7.4.1Basic CapabilitiesBasic capabilities, also known as user grantable capabilities, representdevice functions that are easy enough to comprehend so that a user canreasonably choose whether to accept or reject an application’s accessto them. These functions are not dangerous as far as causing damageto the system or its data, but they can cause unexpected operationand compromise user data if abused.
Examples of functionality controlled by basic capabilities are accessing the phone network, sending anSMS, or initiating a Bluetooth connection. Basic capabilities also protectaccess to potentially private user data such as contacts and calendarinformation.Symbian does not require programs with only basic capabilities to beSymbian Signed; however, there are advantages to getting them signedanyway, as will be discussed shortly.CAPABILITIES FOR API SECURITY221Table 7.1 contains the complete list of basic capabilities.Table 7.1 The Basic CapabilitiesLocalServicesLocationNetworkServicesReadUserDataWriteUserDataUserEnvironmentLet’s look at each of the six basic capabilities listed in Table 7.1 in moredetail.LocalServicesLocalServices protects access to the cost-free, local connections likeBluetooth, Wi-Fi, and infrared that can be made, depending on the devicein question. CBluetoothSocket is an example API class that requiresyou to have this capability, since it sets up a communication path viaBluetooth technology.LocationLocation protects functions on the phone that could get informationabout the device’s location.
CTelephony::GetCurrentNetworkInfo() is an example API that requires this capability, since it returnsinformation about the device such as the device’s current cell ID andlocation area code.NetworkServicesNetworkServices protects access to network connections that mayinvolve cost. Examples of this would be initiating phone calls, sendingSMS, and starting an Internet connection. For example, the RConnection::Start() API function requires this capability.ReadUserDataReadUserData protects access to reading of potentially private user datasuch as text messages, calendar, to-dos, or contact entries. For example,222PLATFORM SECURITY AND SYMBIAN SIGNEDthe API CContactDatabase::OpenL() function, used to open thedevice contact entries for reading, requires this capability.WriteUserDataWriteUserData protects access to private user data described above.Again, using a contacts database function as an example, CContactDatabase::DeleteContactL() would require this capability sinceit modifies a user’s contact database.UserEnvironmentThis capability protects access to the user’s immediate environment.
Thisincludes access to the camera (video and still) and the voice recorder.The API class CCamera is an example of a class with API functions thatrequire the UserEnvironment capability.User granting basic capabilitiesIf an application is not Symbian Signed, the user will be notified if theapplication needs access to a basic capability, and given the choice toreject this access. This can happen in one of two ways: blanket grant orsingle-shot grant.A blanket grant is when the user is notified at install time that theapplication requires them to grant permission to certain features. The usercan choose to continue the installation, if the access seems appropriatefor the application and the user trusts it, or cancel it.In a single-shot grant, the user is notified and given the chance to rejectaccess as previously, but the notification occurs each time the access isactually about to be performed, instead of only once at installation time.It is at the discretion of the phone manufacturer as to which type ofuser grant occurs for each basic capability, and it may even differ acrossdifferent device ranges for a single manufacturer.As an example, say you have developed an application that uses theReadUserData and NetworkServices capabilities as specified in thefollowing line in your MMP file:CAPABILITY ReadUserData NetworkServicesOn the Nokia E61 device (S60 3rd Edition), installing the application willshow the blanket grant prompt for both capabilities (as can be seen inFigure 7.1).As Figure 7.1 shows, the user now knows what the application needsto access.
As a user, you can understand the implications of that accessand choose to either continue or cancel the installation. For example, ifCAPABILITIES FOR API SECURITY223Figure 7.1 Blanket Grant Prompt on E61you are installing a graphics drawing program and see this prompt, youmay be suspicious that it needs access to the network or your contactsdata, so this may cause you to cancel the installation.Note that some manufacturers may decide to enforce a capabilitythrough a single-shot grant instead of a blanket grant at installation.
Inthat case, the user is prompted each time the application tries to accessa function requiring the capability, instead of just once during installation. For example, for NetworkServices, the user would be promptedto reject or continue a network access every time a network access isattempted. As an example, the blanket grant prompt for NetworkServices is shown here for the Nokia E61 (S60 3rd Edition) but may not bedisplayed for phones from other manufacturers, or even some other S603rd Edition devices.Symbian Signing and basic capabilitiesAlthough not required, it can still be preferable to get your applicationSymbian Signed if it uses basic capabilities. When an application isSymbian Signed, it is considered trusted and thus does not prompt theuser for permission to access any functions (blanket or single-shot). Thiscan improve usability, especially if excessive prompting would occurotherwise.7.4.2Extended CapabilitiesExtended capabilities protect APIs that can affect the integrity of thesystem itself.
For extended capabilities, it is not appropriate to promptthe user for permission since: (1) the user would probably not understandwhat the prompt is telling them anyway, and (2) in those situations, theuser probably will not really know what the correct decision to make is224PLATFORM SECURITY AND SYMBIAN SIGNEDsince they have no way of knowing the quality or intent of the code, oreven what the effect would be if the functions were abused.
Applicationsusing APIs that require extended capabilities must be Symbian Signed tobe installed and run.It is entirely possible to write full-featured applications that do notuse any of these extended capabilities. These capabilities are requiredfor advanced programming to tie an application into the device closely(like a program that can globally capture key presses for example, orneeds access to sensitive system settings).
The APIs that these capabilitiesprotect are, for the most part, not covered in this book.Table 7.2 lists the extended capabilities.Table 7.2 The Extended CapabilitiesPowerMgmtProtServReadDeviceDataWriteDeviceDataSurroundingsDDSwEventTrustedUIPowerMgmtThis capability is for power management and controls access to functionssuch as powering off the device and terminating processes. Example APIfunctions protected by this capability are: Power::PowerDown() andRProcess::Terminate().ProtServProtServ gives you the ability to protect a server by adding an ‘!’ to thefront of its name.
We will not cover this concept in this book. Suffice tosay that its purpose is to prevent a third-party server from pretending tobe a system-protected server by spoofing its name.ReadDeviceDataThis capability is required to read critical system device data. For example,you need it to get the phone’s serial number (a.k.a. IMEI) using CTelephony::GetPhoneId().
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
