Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 67
Текст из файла (страница 67)
In future, it maywell be that the algorithms used for selecting which applications shouldbe asked to release memory or exit will borrow ideas from the alreadyestablished problem domain of garbage collecting memory allocators.7.8 SummaryIn this chapter I have talked about the way in which the memory modelmakes use of the physical memory, the cache and the MMU to providethe memory services required by both the Symbian OS kernel- anduser-mode programs.I also showed how the MMU is used to provide memory protectionbetween processes.
In the next chapter, I will talk about how we build onthis basis to provide a secure operating system.8Platform Securityby Corinne Dive-ReclusComputers are like Old Testament gods; lots of rules and no mercy.Joseph CampbellIn this chapter I will introduce a new concept – that of platform security.I will not explore this subject in too great a depth here, as it will shortlybe the subject of a book of its own.1 Instead, I will discuss how thecore operating system components contribute to the implementation ofplatform security on Symbian OS.8.1 IntroductionEKA2 was designed specifically for mobile phones, and so we had tomeet the security requirements of both the mobile phone industry andthe users of those mobile phones.
This meant that we had to understandthose requirements in detail, and in particular to understand the impactthey would have on the essential components of the operating system,such as the kernel, the file server and the loader.To decide how we could implement security in a mobile phone, it wasimportant that we were aware of the user’s perception of her phone, andthe main differences between the well-known desktop environment andthe mobile phone environment:• For our typical end-users, mobile phones are not like computers:people expect them to be simple to use, reliable and predictable• Mobile phones are personal: people do not share their mobile phoneswith others as they share their landline phone or family PC.1Platform Security for Symbian OS, by Craig Heath.
Symbian Press.316PLATFORM SECURITYWhen we asked users what security they expect from a mobile phone,they responded:1.I don’t want nasty surprises when I receive my telephone bill2.I want my private data to stay private!So why not just re-use all the security measures from a desktop computer?The answer, of course, is that phones have specific characteristics, linkedto the physical device itself and the way that it is used, that make themfundamentally different from the desktop environment:1.There are the limitations imposed by the device itself – comparedto a desktop, the screen is small and the keyboard is limited. Thisrestricts the amount of information that can be displayed to the user(typically just one or two short sentences) and also the number andcomplexity of passwords the user is willing to enter2.There is no IT support department to rely on: the user must not beasked questions that she cannot comprehend3.The operating system is hidden: files and even processes are invisible.Let’s take the case of the Sony Ericsson P900: when the user clickson an application, she does not know (and should not need to know)whether this is starting a new process or re-using an existing one.Therefore the user should not be asked to make a security decisionbased on the name of a process or a file.So the main goals of Symbian’s platform security architecture were:1.To protect the phone’s integrity, because users want reliable phones2.To protect the user’s privacy3.To control access to networks, because users care about their bills.Our constraints on platform security were:4.It must be easy for developers to use5.It must be fast and lightweight6.It must only expose security policy to users when they can understand it.The platform security architecture of Symbian OS is based on threekey concepts:1.The OS process is the unit of trustUNIT OF TRUST3172.
Capabilities are used to control access to sensitive resources3. Data caging protects files against unauthorized access.I shall now talk about these concepts in more detail.8.2 Unit of trustWe define a unit of trust as the smallest entity to which we grant a set ofpermissions.8.2.1 ConceptA phone only has a single user, so the security policy is not aboutprotecting different users from each other, as in a desktop environment.Instead, it is about controlling exactly what applications are allowedto do when they run. It was clear that we should choose the unit oftrust to be the process, because this is already the fundamental unit ofmemory protection on Symbian OS.
(As I’ve shown in previous chapters,the kernel cannot protect individual threads from each other if they arerunning in the same process, because they all have unpoliced access tothe same memory.) We identified three main levels of trust, and these areshown in Figure 8.1.8.2.1.1 The Trusted Computing Base (TCB)The Trusted Computing Base (TCB) is responsible for maintaining theintegrity of the device and for applying the fundamental rules of platformsecurity. Very few components – the kernel, the file server and, on openTrusted Computing BaseTrusted Computing EnvironmentApplicationsFigure 8.1 Processes and trust318PLATFORM SECURITYdevices, the software installer and its registry – are part of the TCBand have unrestricted access to the device’s resources. The rest of theoperating system implicitly trusts these to behave correctly; because ofthis, all TCB code is reviewed very strictly.8.2.1.2 The Trusted Computing Environment (TCE)Beyond the core of the TCB, other system components require access tosome, but not all, sensitive system resources.
For example, the windowserver requires direct access to keyboard events, but not to the ETELserver. The Trusted Computing Environment is composed of these keySymbian OS components that protect the device resources from misuse.In Symbian OS, server programs are used to control access to sharedresources, so we define the TCE as the set of all system servers.8.2.1.3 ApplicationsThe final level of trust is ordinary applications. In most cases, thesewill not have any capabilities that can endanger the integrity of thephone, because they will access sensitive resources through componentsin the TCE and the TCB.
In certain circumstances they may requirecapabilities – to access information private to the user, network servicesor local connectivity.8.2.2The kernel’s roleAs I mentioned before, the components in the TCB need to be entirelytrustworthy – and because of this they are reviewed very carefully. Thekey component of the TCB is the main subject of this book, the kernel.In a secure environment, the first duty of the kernel is to ensure theavailability of hardware resources that critical processes require, and toprovide access to those resources in a short, bounded period of time. Iwill discuss the real-time aspects of the kernel in Chapter 17, Real Time,and so will not dwell on them further here.The second duty of the kernel is to provide strong protection of theprocess memory space (including its own) to guarantee that processesare protected against each other and therefore that the behavior of atrusted process cannot be compromised by another process.
This aspectof the kernel is covered in Chapter 7, Memory Models, and again I willnot discuss it further here. Instead I will proceed to enumerate the newsecurity features of EKA2.8.2.2.1 Access to user-mode memoryAny access to user-mode memory from within privileged code (that is,the kernel and device drivers) uses special accessor and copy methodsUNIT OF TRUST319to apply user-mode memory permissions to the access.
This ensures thatinvalid data pointers passed to kernel functions by user processes do notcause the kernel to fail. See Section 5.2.1.5 for more details.8.2.2.2 Thread stacks and heapsThread stacks and heaps are ‘‘private’’ chunks: they cannot be mappedand made accessible to processes other than their owner.8.2.2.3 Process memory overwrittenWhen the kernel allocates memory to a process, it overwrites it withzeroes, to prevent any private data from the previous owner beingaccessible to the new process.8.2.2.4 New IPC frameworkWe have replaced the existing Symbian OS inter-process communication (IPC) framework API (V1) with one designed for trusted IPC (V2).Please refer to Chapter 4, Inter-thread Communication, for more details.Here is an overview of the new features of the framework that provideincreased security:• The new server-side IPC classes have a ‘‘2’’ added to the EKA1 nameto indicate that this is the version 2 of the IPC mechanism: for example,CSession2, CServer2, RServer2, RMessage2, RMessagePtr2• We have removed old, insecure methods that allowed reading andwriting arbitrary process data (for example, RThread::ReadL())and we have replaced them with methods that only allow access todata areas specifically passed by the client in a message (for example,RMessagePtr2::ReadL()).
Now the server can only access datathat is associated with a valid message and it must now use theRMessagePtr2 class to do this. This also means that the data is notavailable to the server after it has processed the message• Parameters passed in an IPC request are now typed for increasedrobustness. For extra security, their lengths are also specified, even inthe case of a pointer, to ensure that the server will not read or writemore than the client expected to disclose: any attempt to read beforethe pointer’s address or beyond its length will fail.8.2.2.5 ARM v6 never-execute bitIf the hardware supports it, then EKA2 will take advantage of the ARMv6never-execute bit in the page permissions (see Chapter 7, Memory Models, for more on this). This is used to deny the execution of code from320PLATFORM SECURITYstacks, heaps and static data, with the aim of preventing buffer-overflowattacks.
(These inject malicious code into stacks or heaps over the limitof an array passed as a function parameter to trick a process into executing that code.) EKA2 only allows execution from execute-in-placeROM images, software loaded by the Symbian OS loader and explicitly created ‘‘local code’’ chunks (for compiled Java code such as JITor DAC).8.3 Capability model8.3.1 ConceptA capability is an authorization token that indicates that its owner has beentrusted to not abuse resources protected by the token. This authorizationtoken can grant access to sensitive APIs such as device driver APIs or todata such as system settings.8.3.2Capability rulesThe following capability rules are fundamental to the understandingof platform security.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
