Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 69
Текст из файла (страница 69)
They are a usefulabstraction guaranteeing binary compatibility to developers by isolatingthem from changes in the underlying internal format.326PLATFORM SECURITYNow suppose that ODE.EXE does not have the network servicescapability. What happens if ODE decides to bypass ETEL by talking toC32 directly? This will not work – C32, knowing that some requests cancome from external processes, does its own policing.What will happen if ODE decided to talk to the base band devicedrivers directly? This still will not work: these device drivers cannot beused without the system capability CommDD.Or perhaps you might think that you could write your own devicedriver to access the hardware.
That will not work either – device driversrun within the same process space as the kernel, and the rules describedin Section 8.3.1 would require this device driver implementation to haveat least the same set of capabilities as the kernel itself.The key points that you should bear in mind from this discussion are:• Capabilities are only worth checking when a process boundary couldbe crossed• The kernel is the trusted intermediary between a client and a server.8.3.4 Device driversDevice drivers run inside the kernel and so have access to all theresources of the mobile phone, without restriction. They are implicitlypart of the TCB. Because of this, it is very important that drivers checkthe capabilities of user-side processes and that they protect themselvesagainst bad parameters passed in by a client.
For example, if a maliciousclient passes a pointer into another process or even the kernel, and thedevice driver does not check that the client has the correct permissionsto access that memory, then the client is able to bypass platform securityand fool the driver into returning secret data.The general rules for device driver writers are:1.Check that the client has sufficient capabilities to access the functionality provided by the driver2.Do not trust any parameters passed in by the client; check that allparameters are valid3.Do not use pointers passed by the client directly – always use thekernel functions that access the memory using the client’s permissions(kumemget(), kumemput(), Kern::ThreadDesRead() and soon)4.Device driver channels cannot be passed between processes.For device drivers that are split into LDD and PDD parts, the recommended practice is to perform all client capability checking at the LDDlevel.
This ensures the policy is provided consistently and securely acrossall physical driver implementations.DATA CAGING3278.4 Data caging8.4.1 ConceptThe capability model is the most fundamental concept of platformsecurity. Data caging, another key concept, is much more specific: itis about file access control. As I said at the beginning of this chapter,phones are single-user devices, so the emphasis is not on controlling theuser’s access to files, but on controlling the file access of the variousprocesses running on her phone.One point to bear in mind is that, compared to a typical desktopenvironment, phones are resource-constrained – they may have limitedstorage space, slow processors and limited battery life. It is vital thatplatform security does not reduce the speed of file access, or increasepower consumption or the size of file system itself.The solution that we came up with was to move away from traditionalaccess control lists, and to implement a fixed access control policy thatcan be fully described by the following sentence:Rule 3.
The access rules of a file are entirely determined by itsdirectory path, regardless of the drive.We identified four different sets of access rules, which we represent byfour separate directory hierarchies under the root ‘‘\’’.8.4.1.1 \sysOnly TCB processes can read and write files under this directory. Thisdirectory tree contains data vital to the integrity of the platform, such asexecutables.8.4.1.2 \resourceAll processes can read files in this directory, but only TCB processes canwrite to them. This directory mostly contains bitmaps, fonts and help filesthat are not expected to change once installed.8.4.1.3 \privateThe file server provides all programs with a private sub-directory under\private, regardless of their level of trust.
Only the appropriate process,TCB processes and the backup server can read and write files in a process’sprivate directory. Other processes may neither read nor write.8.4.1.4 All other root files and directoriesThere is no restriction on what a process can do to a file stored in anyother directory, including the root directory itself. These are all completelypublic spaces.328PLATFORM SECURITY8.4.2 Implementation8.4.2.1 Program SIDEach program must be assigned a unique identifier, called the secureidentifier or SID, so that the kernel can provide a private space for eachprogram.
At ROM-build time and install time, the system will guaranteethat each SID is uniquely associated with one executable. SIDs areassigned at compile time and specified in MMP files. If the MMP file doesnot define a SID, then the tool chain will use UID3 as the SID. If theprogram does not have a UID3, then the value of KNullUid is assigned.As a consequence, all processes with no SID and a null UID will sharethe same private directory.8.4.2.2 Capabilities and file accessAs well as the SID, there are two capabilities that we created to controlaccess to data-caged directories:1.TCB – grants write access to executables and shared read-onlyresources2.AllFiles – grants read access to the entire file system; grants writeaccess to other processes’ private directories.The access rules are summarized in the following table:Capability required to:ReadWrite\resourcenoneTCB\sysAllFilesTCB\private\<ownSID>nonenone\private\<other>AllFilesAllFiles\<other>nonenoneIt may sound strange that TCB processes also need the AllFilescapability to be able to read under \sys.
This decision was made for thefollowing reasons:• Capabilities should be fully orthogonal to each other: one shouldnot be a subset of another. This is to eliminate the use of OR incapability checking, which creates ambiguity about what a capabilityreally grantsDATA CAGING329• We identified a need to provide a capability to grant read access tothe entire file system without implying that write access to \sys hadto be granted: this reflects the distinction that has been made betweenTCB and TCE processes.8.4.2.3 The role of the file server and the loaderAll executables are now stored under \sys\bin. The file server enforcesthe rule that only TCB processes can write into this directory, to ensurethat executables cannot be modified.
Non-TCB processes cannot injectnew code into existing executables and cannot change the capabilityset. This is a powerful way of ensuring the integrity of executableswithout requiring that each executable has to be signed and its signatureverified every time it is loaded. If executables are installed in directoriesother than \sys\bin, then this is harmless, as the loader will refuse toload them.This means that normal processes can no longer scan for executables, as they will not have the permissions to do so. The path of anexecutable is therefore irrelevant, and only the drive, name and typeof file are important. This gives Symbian OS the flexibility to organizethe storage of its executables at it sees fit without breaking backwardscompatibility. In Symbian OS v9, all executables are stored in \sys\bin;there are no subdirectories. It is even more important than before tochoose a ‘‘good’’ name for your executables, for example by prefixing them with your company name.
If any clash is identified at installtime, the software installer will indicate the conflict to the user andcancel the installation. This may seem harsh, but it is a very effectivemeasure against Trojan horse attacks in which a malicious file triesto be seen as a legitimate one. Another side effect of this decision isthat loading is faster, since we have reduced the number of directories to scan and simplified the algorithm used to decide which file toload. See Chapter 10, The Loader, if you want to find out more aboutfile loading.What about installed binaries on removable media – including thosethat are subst-ed as internal drives? In this case the path <drive>:\sys\bin cannot be deemed to be secure, because the removable mediummight have been removed and altered elsewhere.
Some tamper evidenceis needed to detect whether the contents of a binary file have beenchanged since they were known to be safe – which was when they wereinstalled. To do this when it first installs an executable onto a removablemedium, the Symbian OS installer takes the additional step of computinga secure hash of the binary and storing this in the tamper-proof \sysdirectory on the internal drive.Subsequent attempts to load the binary from that medium will fail if asecond hash computed at load time does not match the one stored in theinternal \sys directory, or if the internal hash does not exist at all.330PLATFORM SECURITY8.4.2.4 Sharing files between processesSymbian OS has a variety of ways of allowing processes to share data,including publish and subscribe, DBMS (Symbian’s relational database)and the central repository (Symbian’s service to share persistent settings).These methods, and others, have their uses, but nevertheless we stillneed a means for one process to share a file with another process undercontrolled conditions.
For example, a messaging application might wishto launch a viewer application on a message attachment, but withoutrevealing all other attachments to that viewer process, or revealing theattachment to all other process. EKA2 gives us the basic building blocks,by providing a way of sharing handles across processes, and the file serversupports this feature for file handles.The process that owns the file opens it in a mode that cannot bechanged by the process receiving the file handle without the file serverrechecking that file’s access policy against the receiving process’s credentials.The receiving process gets access to a shared session and file handles,but it does not get access to the shared file’s parent directory or to otherfiles in the same parent directory.If you want to share files like this, you should be aware that, in theowning process you should open a file server session specifically for filesharing, open any files you wish to share and no others, and then closethe session as soon as it is no longer needed (that is, once the receivingprocess has done what it needs to with the shared files).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
