Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 68
Текст из файла (страница 68)
They strongly reenforce the first concept that theprocess is the unit of trust. They are worth reading carefully; they aresomewhat less obvious than they may first appear.Rule 1. Every process has a set of capabilities and its capabilitiesnever change during its lifetime.To build a Symbian OS executable, you have to create a project file(MMP).
The Symbian OS build tools now require an additional line thatdefines what capabilities should be given to the executable in question.The build tools will read the MMP file and write the desired capabilitiesinto the resulting binary, just as they do with UIDs.MMP files are used to associate capabilities with every sort ofexecutable code. Programs (.EXE), shared libraries (.DLL) all have theircapabilities defined in this way.
When it creates a process, the kernelreads the capabilities from the header of the program file on disk andassociates those capabilities with the process for the remainder of its lifetime. The kernel stores the capabilities in memory, which is inaccessibleto user-mode processes, to prevent tampering. It provides user-side APIsto allow user-side code to check that a process requesting a service has aspecific set of capabilities.In the following example, litotes.exe has been assigned twocapabilities, ReadUserData and WriteUserData.
These grant theapplication access to APIs that access and modify the user’s private data,such as contacts.CAPABILITY MODEL// litotes.mmpTARGETTARGETTYPEUIDSOURCEPATHSOURCEUSERINCLUDESYSTEMINCLUDE...CAPABILITY321litotes.exeexe0x00000000 0x00000123..\litsourcelitotes.cpp..\include\epoc32\includeReadUserData WriteUserDataSymbian OS provides three main methods for programs to use servicesprovided by other executables:1. Loading a DLL and calling its API2. Making requests of server programs3.
Loading and calling a device driver.In each case, the caller’s capabilities must be checked. I will explain howthis is done, taking each of these cases in turn.8.3.2.1 Loading a DLLAs mentioned earlier, a DLL is executable code and its binary will containa set of capabilities. But a DLL must always execute within the contextof a process – the process that loads the DLL – and rule 1 stated that thecapabilities of a process can never change. Together, these statementsimply that the DLL code must run at the same capability level as theloading process. This leads to the principle of DLL loading, rule 2:Rule 2.
A process cannot load a DLL that has a smaller set ofcapabilities than it has itself.The need for this constraint follows from the fact that all DLL coderuns at the capability level of the loading process. This means that DLLcapabilities are different to process capabilities, in that they don’t actuallyauthorize anything; they only reflect the confidence placed in them tonot abuse or compromise a host process with those capabilities.DLL capabilities are policed by the loader, and so are checked only atload time.
After that, all the code contained in the DLL will run with thesame capabilities as the code directly owned by the process. This meansthat it will be subject to the same capability checking when it accessesservices provided by other processes.Rule 2b. A DLL cannot statically link to a DLL that has a smaller setof capabilities than it has itself.322PLATFORM SECURITYRule 2b is a corollary of rule 2, as you can see if you replace theword ‘‘process’’ in rule 2 with the words ‘‘loading executable’’ – but it isclearer to restate it as I have just done.The Symbian OS loader directly resolves static linkage between theloading executable (program or library) and the shared library.
So, whena library is linked to another library, the loader does not take into accountthe top-level program. To see why, let’s look at an example. Assume thata DLL, METAPHOR, with capability ReadUserData, wants to staticallylink to a DLL without this capability, SIMILE. When the linker resolvesthis static direct linkage, it does not know whether METAPHOR will bestatically linked to a program with or without ReadUserData. If the finalprogram EPITHET does have ReadUserData, and if METAPHOR werestatically linked to SIMILE, then this would be unsafe as SIMILE mightcompromise EPITHET ’s use of ReadUserData capability.Hence the secure route is to always reject the linkage when the linkedDLL has a smaller set of capabilities than the linking one.
This is illustratedin Figure 8.2.STEP 1: EPITHET.exe is loaded firstSTEP 2: EPITHET2.exe is now loadedEPITHET.exeEPITHET.exeNoneEPITHET2.exeReadUserDataNonelinked tolinked toMETAPHOR.dlllinked to: OKMETAPHOR.dllReadUserDatalinked toReadUserDatalinked to: NOT OKSIMILE.dllSIMILE.dllNoneNoneFinal result: all code runs without any capabilityFinal result: all code will run with capability ReadUserData, including SIMILEthat is not trusted with this privilege.CONCLUSION:To enforce security in all cases, METAPHOR.dll must not be allowed to load SIMILE.dllFigure 8.2 Capability rules and DLL linkingRule 2 and its corollary prevent malicious or un-trusted code beingloaded into sensitive processes, for example a plug-in into a system server.The rules also encourage the encapsulation of sensitive code inside wellknown processes.
The loader provides this security mechanism for allprocesses; relieving them of the burden of identifying which DLLs theycan safely load or link to.The following examples show how these rules are applied in the casesof statically and dynamically loaded DLLs respectively.CAPABILITY MODEL3238.3.2.2 Examples for statically linked DLLsAssume that the program PLOT.EXE is statically linked to the libraryRHYME.DLL and the library RHYME.DLL is statically linked to the libraryREASON.DLL.Example 1Also assume that:1. PLOT.EXE holds Cap1 and Cap22.
RHYME.DLL holds Cap1, Cap2 and Cap33. REASON.DLL holds Cap1 and Cap2.Then the load fails because RHYME.DLL cannot load REASON.DLLaccording to rule 2b.Example 2Also assume that:1. PLOT.EXE holds Cap1 and Cap22. RHYME.DLL holds Cap1, Cap2 and Cap33. REASON.DLL holds Cap1, Cap2 & Cap3 and Cap4.Then the load succeeds; however RHYME.DLL cannot acquire the Cap4capability held by REASON.DLL, and PLOT.EXE cannot acquire theCap3 capability held by RHYME.DLL due to rule 1.8.3.2.3 Examples for dynamically loaded DLLsAssume that the program PLOT.EXE dynamically loads the libraryRHYME.DLL and the library RHYME.DLL then dynamically loads thelibrary REASON.DLL.Example 1Also assume that:1. PLOT.EXE holds Cap1 and Cap22. RHYME.DLL holds Cap1, Cap2 and Cap33. REASON.DLL holds Cap1 and Cap2.The load succeeds because PLOT.EXE can load RHYME.DLL andREASON.DLL.
You should note that the loading executable is theprocess PLOT.EXE and not the library RHYME.DLL, because the RLibrary::Load() request that the loader processes is sent by the process324PLATFORM SECURITYPLOT.EXE. The fact that the call is within RHYME.DLL is irrelevant: onceloaded the code from RHYME.DLL is run with the same capability set asPLOT.EXE (rule 1).Example 2Also assume that:1.PLOT.EXE holds Cap1 and Cap22.RHYME.DLL holds Cap1, Cap2 and Cap33.REASON.DLL holds Cap1, Cap2 and Cap4.Then the load succeeds because PLOT.EXE can load RHYME.DLL andREASON.DLL.
Because of rule 1, the code loaded from RHYME.DLL andREASON.DLL will be run with the same capability set as PLOT.EXE – thatis Cap1 and Cap2.8.3.3 Client-serverThe servers that make up the TCE police incoming requests from theirclients to ensure that those clients hold the required capabilities. Forexample, if a client asks the ETEL server to make a phone call, ETELchecks that the client has the ‘‘network services’’ capability.An alternative approach to restricting access that is sometimes usedin security architectures is a check based on the caller’s identity, using,for example, an access control list.
The approach used by SymbianOS platform security is preferable, because adding a new requester (forexample a new client of ETEL) does not impact the security policy of theenforcer, ETEL.A server typically offers many functions to its clients, and each of thesefunctions can require a different set of different capabilities, or none atall. The capabilities required may also differ according to the data theclient passes to the server – for example, the file server’s function to opena file does not require any capabilities if the client wants to open its ownfiles, but requires a system capability if the client wants to open a file thatit does not own.This security check does not affect the way in which IPC messages areformatted.
It would be pointless to require a client to pass its capabilitiesto the server directly, since a badly behaved client could lie aboutthem. Instead, the kernel adds client capabilities to the IPC message as ittransfers the call from the client to the server side.Figure 8.3 shows an application ODE.EXE that wants to dial a phonenumber by invoking RCall::Dial().
This method is just a front-end toa client-server IPC communication.The kernel receives the IPC message and adds ODE ’s capabilities to itbefore dispatching it to the ETEL server. ETEL can trust it to do this, sincethe kernel is part of the TCB.CAPABILITY MODEL325processboundaryODE.exeC32exe.exethreadNetworkServicesNetworkServicesETEL serverC32 serverRCall::Dial(n)userkernelIPCCommDDLogical DDPhysical DDKEYUser capabilitiesSystem capabilitiesFigure 8.3 Runtime capability checkingETEL can access ODE ’s capabilities via the RMessage2 class. It verifiesthat ODE has the network services capability before accepting the request.Several classes exist to help servers check access to their services:• The server should derive from CPolicyServer• Mapping of IPC messages and security policies are defined by usingCPolicyServer::TPolicy• Security policies are defined by using TPolicyElement whichprovides verification services such as:IMPORT_C TBool CheckPolicy (RMessagePtr2 a MsgPtr, const char*aDiagnostic=0) constThese classes hide the format used to store capabilities.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
