Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 45
Текст из файла (страница 45)
Reading the phone’s lock code and list ofinstalled applications are other examples.CAPABILITIES FOR API SECURITY225WriteDeviceDataThis capability protects the writing of device data. This protects writing of some parameters outside of the ones ReadDeviceData protects. For example, the system time can be read without ReadDeviceData, but can only be written if you have WriteDeviceData.Other device parameters protected include lock settings, alarms, andtime zone.SurroundingsDDThe DD in the name refers to device drivers. This capability protects accessto device drivers that allow you to know about the phone’s surroundings,such as GPS hardware.SwEventThis capability protects the capturing of key presses and the ability toproduce virtual key events. These functions are needed by things likescreen capture programs that rely on a hotkey being selected to capturethe screen.
Another example would be a key capture virus that recordsall your keystrokes to send off to your computer on the network (but thatuse case is unlikely to be approved by Symbian Signed!).TrustedUIThis capability provides the ability to create a trusted dialog in a waythat cannot be reproduced by an application without this capability. Thepurpose is to assure a user that, if they see it, they can enter sensitiveinformation, such as their banking PIN, and it won’t be stolen by anotherapplication that is pretending to be the trusted one. This is rare, and infact not supported in Symbian OS v9.1.7.4.3 Phone Manufacturer CapabilitiesPhone manufacturer capabilities protect access to the most critical APIsand data on the phone.
As with extended capabilities, applications withphone manufacturer capabilities must be signed before the applicationcan be installed. The capabilities are reserved for advanced system-levelsoftware and are not easy to get authorized. In addition to the SymbianSigned process described in section 7.5.2, there is an extra step involvedto get approval from the manufacturer of the handsets for which thesoftware is intended (e.g., Nokia or Sony Ericsson). Table 7.3 lists thecapabilities in question.226PLATFORM SECURITY AND SYMBIAN SIGNEDTable 7.3 The Phone ManufacturerCapabilitiesAllFilesCommDDDiskAdminMultimediaDDNetworkControlDrmTcbAlthough the functions protected by phone manufacturer capabilitiesare for the most part outside of the scope of this book, let’s discuss eachcapability in Table 7.3 in a little more detail.AllFilesAllFiles gives you read access to the entire file system.
You can readmost of the file system without it, but this capability additionally gives youread access to the \sys directory where the executables are stored (butnot write access). Most critically though, AllFiles gives you read andwrite access to all the subdirectories of the \private directory whereapplications store their private data. I’ll discuss the concept of file systemdata caging shortly in section 7.4.8.CFileman::Copy(), for example, requires this capability if thesource or destination of the copy is a private directory.AllFiles is rarely approved by a phone manufacturer since thiscompromises all private application data on the phone.
The most commonusers of this capability are the manufacturers themselves, for internaldevelopment and test tools.CommDDThis capability is needed for direct access to communication drivers suchas those for Wi-Fi and USB connectivity.DiskAdminDiskAdmin controls access to disk administrative functions like formatting a drive, mounting and unmounting a file system, and otherdisk-handling functions. RFs::CheckDisk() is an example API thatrequires this capability.CAPABILITIES FOR API SECURITY227MultiMediaDDMultiMediaDD is needed if you want direct access to multimedia devicedrivers like audio and camera or priority access to multimedia APIs.NetworkControlNetworkControl is required for controlling network connections andprotocols.
An example is stopping a network connection with RConnection::Stop().DrmThis capability provides access to music protected by Digital RightsManagement and encrypted on the device. As you can probably guess,it is hardly ever granted by phone manufacturers except to their trustedpartner companies.TcbAllows complete read and write access to the entire file system (AllFiles gives read/write access to the \private directory but not to\sys or \resource). The Trusted Computing Base (TCB) forms a criticalpart of platform security and the Tcb capability is reserved for a very fewcomponents that form the core of Symbian OS.
For more about the TCB,you should consult [Heath].7.4.4 How Do You Know Which Capabilities You Need?To find out what capabilities you need, your first stop should be theSDK documentation. The API reference section should tell you whatcapabilities are needed to access each API. However, there are caseswhere the SDK documentation does not mention the capability needed,or is unclear.The best test sometimes, unfortunately, is trial and error performed byplugging capabilities into the MMP file until you find the one(s) you need(remember, an API will usually return KErrPermissionDenied if thecaller does not have the capability needed).
You can do this on the devicefor basic capabilities, however, this would not work when trying to findextended or manufacturer capabilities since you would not be able toinstall this to your device with these capabilities without being SymbianSigned.The best way to experiment in order to determine the platform securitycapabilities required by your application is to use the Symbian OSemulator.
The emulator will enforce the access specified in your MMP228PLATFORM SECURITY AND SYMBIAN SIGNEDfile for capabilities (in the same manner as a device), but without requiringyour application to be Symbian Signed.The next section discusses some emulator configuration options relatedto platform security.7.4.5 The Emulator and Platform SecurityThe emulator has configuration options related to platform security thatcan be useful for development. You can set these configuration optionsin the emulator configuration file \epoc32\data\epoc.ini.PlatSecEnforcementPlatSecEnforcement enables or disables platform security enforcement. When enabled, if a platform security check fails, the appropriateaction is taken (which is typically to generate a KErrPermissionDenied error or leave).
If platform security enforcement is disabled,however, the system continues as if the check passed. To enable, enterthe following in epoc.ini:PlatSecEnforcement OnTo disable:PlatSecEnforcement OffThe default for the emulator is for security enforcement to be enabled.You may want to disable security enforcement, for example, in the earlystages of your project when you are concentrating more on program logicthan security.PlatSecDisableCapsPlatSecDisableCaps can be used to selectively disable specific capabilities. For example, if you have:PlatSecEnforcement OnPlatSecDisableCaps Location NetworkControlin the epoc.ini file, then all capabilities will be enforced exceptLocation and NetworkControl. The emulator will bypass any checksfor this capability in the system APIs.CAPABILITIES FOR API SECURITY229PlatSecDiagnosticsPlatSecDiagnostics enables and disables logging of platformsecurity-related failures to epocwind.out.
From this log you can tellwhat APIs failed due to permission errors.To enable, enter the following in epoc.ini:PlatSecDiagnostics OnTo disable:PlatSecDiagnostics Off7.4.6 Defining Capabilities For Your ProjectAs previously mentioned, you specify the capabilities your process needsin the MMP file using the CAPABILITY keyword. In the Carbide.c++development tool, you can specify it in the project properties dialog,under C/C++ build. Select the tool settings tab and the system optionsunder that.If you do not have a CAPABILITY line in your MMP file, then thedefault is that you have no capabilities.
CAPABILITY NONE specifies thesame thing.The basic way of specifying capabilities is to enter each capabilityneeded after the CAPABILITY keyword, separated by spaces.CAPABILITY ALL means to use all capabilities. The ‘–’ sign can beused to subtract capabilities from CAPABILITY ALL.For example, the line:CAPABILITY ALL -Tcb -AllFiles -Drm -CommDD -Multimedia -NetworkControl-DiskAdminmeans all capabilities except the phone manufacturer capabilities (Tcb,AllFiles, Drm, CommDD, Multimedia, NetworkControl, andDiskAdmin).7.4.7 Capabilities in DLLsAs mentioned previously in section 7.4, capabilities are defined at theprocess level. Since a DLL function executes in the same context as thecalling process (i.e., it runs as part of that process), then the DLL functionalways executes with the calling process’s capabilities.230PLATFORM SECURITY AND SYMBIAN SIGNEDYou must still specify capabilities in your DLL’s MMP file (or Carbide.c++ project properties), but the meaning is different than it is for aprocess.
Specifying capabilities in a DLL means that the DLL is trustedto run within a process that has those capabilities, not necessarily that itactually uses those capabilities.Capabilities in DLLs can be summarized by the following two rules:1.A DLL must have at least the capabilities of its calling process.2.When executing, a DLL function always inherits the capabilities ofthe calling process (and no more).For the first rule, if a process tries to load a DLL that does not haveall of the capabilities of the process, it will fail.
It’s fine, however, ifthe DLL has capabilities that the calling process does not have. Anotherway of saying this is that the calling process’s capabilities must be asubset of the DLL’s capabilities. Following is an example to illustratethis.If you have the following capabilities in your process (as specified inyour MMP):CAPABILITY ReadUserData ReadDeviceDataand in your DLL, you have:CAPABILITY ReadUserData WriteUserData NetworkServicesthen the process will not be able to load and use your DLL sinceit does not have ReadDeviceData.
The DLL would have to haveboth ReadUserData and WriteDeviceData as a part of its declaredcapabilities for that process to use the DLL.The second rule is just a recap of what we discussed before about theDLL functions always running with the same capabilities as the callingprocess.Following is an example to illustrate the second rule.If your process has these capabilities:CAPABILITY ReadUserData WriteUserData NetworkServicesand the DLL has:CAPABILITY ReadUserData WriteUserData NetworkServices NetworkControlCAPABILITIES FOR API SECURITY231then your process will be able to load and use the DLL since it does containat least the capabilities of the calling process.
However, the DLL code willjust have ReadUserData, WriteUserData, and NetworkServiceswhile executing from a call from that process, since it inherits only thecapabilities assigned to the calling process.You’ll want to be safe and ensure that your DLL contains all thecapabilities a calling process may have so that the process can use theDLL (as per rule 1). However, like a process, your software will need tobe Symbian Signed if the DLL specifies extended or phone manufacturercapabilities in its MMP – even if the DLL does not use any of the APIsprotected by those capabilities. In that case, it’s fairly easy to justify havingthem if you can guarantee that the DLL can be trusted in a process thatdoes possess those capabilities.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
