The Symbian OS (779886), страница 22
Текст из файла (страница 22)
Recent initiatives such asEclipse, for example, or the adoption of the standard ARM EABI are likelyto continue to change the story of the development tools.25 Again, usingmanifest constants provides the necessary level of decoupling of codefrom compiler dependencies.The key classes are summarized as follows:26• TInt and TUint are the generic types for signed/unsigned integervalues; TInt8, TInt16, TInt32, and TUint8, TUint16, TUint32are also provided; in general, the least specific types are preferred,that is, TInt and TUint• TInt64 is a 64-bit integer type intended for platforms without anative 64-bit type25Symbian, like Psion before it, has always assumed that mainstream development isdone under Microsoft Windows, although this is not the only solution that works. There area number of independent open-source solutions for developers wanting to work on Linuxor Mac OS X.26Again, [Stichbury 2005, Chapter 1] provides a comprehensive discussion.82INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OS• TReal, TReal32 and TReal64 are single- and double-precisionfloating-point types; again the least specific type, TReal, is preferred• TText8 and TText16 are 8-bit and 16-bit unsigned types for characters• TBool is a 32-bit unsigned Boolean type• TAny* is used instead of void*.Unique IdentifiersUnique identifiers (UIDs, implemented as signed 32-bit values) are centrally controlled in Symbian OS.
One common usage of them is to identifyapplications and other binary and data types. UIDs, for example, are usedin Symbian OS to associate data types with programs and plug-in typeswith frameworks. UIDs are also used as feature IDs and package IDs (forSIS files).Charles Davies:The idea was that if you had polymorphic DLLs, dynamic libraries in otherwords, then there are situations where the DLL is a plug-in, and it all goes verywrong if the caller doesn’t get the interface it’s expecting from the DLL, so weneeded to characterize the interface.
And we came up with the idea of usinga UID to do that.UIDs are used in a three-tier construction to build TUidType objects:• UID1 – a system level identifier that distinguishes EXE from DLL types• UID2 – a specifier for library types that distinguishes between sharedlibrary DLLs and various types of polymorphic DLL (for example FEPsand other types of plug-in)• UID3 – the individual component ID, also used by default as thesecure identifier (SID) required by platform security.27UID3 is used, for example, by developers to uniquely identify theirapplications, and can then be used by the streams, stores and files createdby that application to identify themselves.
UID3 is assigned throughSymbian’s UID allocation database, from which third-party developerscan request blocks of UIDs for use in their applications.Platform Security introduces two new types of UID, the SID (SecureID), which by default is identical to UID3, and VID (Vendor ID).27See the discussion in [Sales 2005, p. 328].PLATFORM SECURITY FROM SYMBIAN OS V9833.8 Platform Security from Symbian OS v9Platform Security is the system-wide security model introduced in Symbian OS v9.
Providing an open, third-party programmable platform hasbeen an important principle in the development of Symbian OS. However, openness brings with it the risk of misbehaving software (whetheraccidentally or deliberately misbehaving) finding its way onto users’devices. The security model is designed to protect users from that risk,while still preserving the openness of the platform.Architecturally, Platform Security is a set of pervasive changes at alllevels of the system, based on a simple conceptual model,28 which isdeliberately as lightweight as possible, and supported by the SymbianSigned certificate signing program, which provides a means for creatinga formal link between an application and its origin, as well as providinga review mechanism to promote best practice in designing and writingSymbian OS applications.Will Palmer is one of the system architects who is currently responsiblefor the Platform Security project.Will Palmer:There are three principles to Platform Security.
The first principle is the unit oftrust, the idea of the process being the unit of trust. Since memory is alreadyprotected per-process on the processor, that fits quite nicely, and it also has theadvantage of being a ‘least-privilege’ approach, based on the smallest elementin the operating system. The second principle is the idea of capabilities, whichare in effect authorization tokens.
So to be able to access a potential resource,a process needs to possess a particular capability that allows it to do so. Andthe third principle is data caging, which is about read and write protection offiles, which protects the integrity of data as well as protecting data from pryingeyes.The essential principles are:• processes as the unit of trust,29 which turns trust into another processgranular system resource• capabilities as the tokens of trust, which are required to performactions28According to [Heath 2006, p. 18], the model conforms to the eight design principlesof [Saltzer and Schroeder 1975], which include economy, openness, least privilege andpsychological acceptability.29This is an elegant extension of the kernel’s process model, in which the process is theunit of ownership of all system resources (for example, memory protection is per process).84INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OS• data caging, which protects data from prying eyes (by policing readaccess) or interference (by policing write access) or both.The direct consequence of defining the process as the unit of trust isthat all threads in a process share the same level of trust (which is natural,since they have access to the same resources).The goal is to protect device users from the kinds of intentionallyrogue software, or ‘malware’, that plague the PC world.
Symbian OS fora long time avoided some of the worst threats from malware because itwas typically deployed in ROM-based devices, in which the system itselfcannot be corrupted (for example, it is impossible to install trapdoorsor trojans in system files) because system code is stored in unwriteableROM memory. By design, Symbian OS also protected against some ofthe more trivial security holes found on other systems.
Descriptors, forexample, make buffer overrun attacks much harder. Similarly, Symbian’smicrokernel architecture helps to increase security and robustness; sincethe trusted kernel is deliberately the smallest possible subset of systemfunctions, there is little privileged code to exploit, and the smallercodebase is easier to review and validate.The nature of mobile devices, especially phones, also makes themdifferent from desktop systems. The physical access model is different(personal devices are less likely to be shared) and the network accessmodels are different (connections are transient).On the other hand, phones also present new opportunities for malware.If a phone, or user, can be spoofed into making a call, real money isat stake.
(Premium-rate-phone-number scams are an example.) Froma network perspective, the cost of network disruption is immediatelycommercially quantifiable in a way that Internet attacks are not.These differences all require appropriately designed security mechanisms.Will Palmer:When the capability model was designed there were a set of constraints aboutwhat it had to deliver: it had to be robust; it had to be simple; and it shouldn’tget in the way of the operation of a phone so, for example, you couldn’t usehundreds of extra clock cycles on it, because on a small device you haveperformance and power constraints. Also it had to be appropriate for an openoperating system: people have to be able to install additional software on theirphones and it has to be simple and easy to understand.Data caging, for example, was chosen for its simplicity and economy(in terms of clock cycles and power).
Another important considerationwas that mechanisms which users are quite comfortable with on desktopcomputers – logging on, for example – would be quite inappropriate ona phone.PLATFORM SECURITY FROM SYMBIAN OS V985Will Palmer:Authorization based on the process–capability model is simple to understandand it fits the phone case much better than an authentication system. So inan authentication system you log on and your password authenticates you tothe system, and once authenticated you can do anything permitted by yourauthentication level. But a phone is different: it’s a single-user environment;it’s in your pocket; it belongs to you.
Although things are getting more complexnow because of requirements coming in for administrative rights. For example,the network operator might want to change settings on the phone.The capability mechanism is used to protect both ‘system’ and ‘user’(i.e., application-owned) resources. Will Palmer sums up the differenceneatly.Will Palmer:It’s not that some types of capabilities are more powerful than others, they justprotect different things. System capabilities protect the integrity of stakeholdersand of the device, whereas user capabilities protect the user’s privacy andmoney.Protected APIs are tagged at method-level with the capability requiredto exercise them and access any underlying resources (data files, forexample).
The capabilities of a method are part of its interface. To useprotected APIs therefore, developers must request an appropriate set ofcapabilities, which is done through the Symbian Signed program.A ‘signed’ application is granted a set of capabilities. Applicationcapabilities are verified by servers when protected APIs are called byapplications. Unsigned software is flagged to the user at installationtime as being unsigned (and therefore untrusted). Thus, while unsignedapplications can assign any user capabilities to any binaries as theysee fit, the user is alerted at installation time and given the option toapprove the application or not.
Unsigned applications cannot use systemcapabilities, in other words they cannot use APIs which affect the behaviorof the device. Data security is provided on a per-application basis by thedata-caging model.4Introduction to Object Orientation4.1 BackgroundSymbian OS is a full-blown, from-the-ground-up, object-oriented system.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
