Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Symbian Security
Symbian uses a three-layer model for security. At the core is the trusted computing base (TCB). The term "trusted computing" seems to send Free Software Foundation members scurrying for their pitchforks and flaming torches, but a TCB is a fairly common security concept. It's the bit of code that you have to trust; if it contains bugs, the entire system is compromised. For secure systems, you want the TCB to be as small as possible. The TCB for Symbian includes the kernel, drivers, and file server.
Between the TCB and normal applications is the Trusted Computing Environment (TCE). This set of userspace processes has slightly closer access to the low-level services than the rest of the system does. The TCE includes things like the window server, which needs to get at raw key events, and can be thought of as "owning" the screen. The window server's job is to mediate access to the screen for other applications, just as the kernel's job is to mediate access to the CPU.
Remember that Symbian was designed for handheld devices. Unlike UNIX, which was designed for minicomputers, Symbian wasn't intended to be a multiuser system. A modern UNIX machine often has only a single real user, and it uses the multiuser facilities to implement a privilege-separation model. Symbian also has only one user, but applications can have a restricted set of capabilities. This difference is very important, because malicious code can easily do things on a mobile phone that will cost the user a lot of money, such as phoning premium-rate numbers. Each Symbian process comes with a set of capabilities that are set when the process is created and cannot be modified.
The interaction between capabilities and the dynamic loader is quite interesting. Each shared library also has a set of capabilities. A process can only load libraries that have all of the capabilities of the process, because the loaded code will run with the capabilities of that process. If the shared library isn't trusted with a certain capability, it shouldn't be loaded by a process that has that capability. If the shared library is trusted with a capability, but the running program isn't, the code in the library cannot use that capability in that process.
Because the capability flags for a process are attached to every IPC message that the process sends, things like the window and network servers can enforce security easily. If a program doesn't have the capability bit required for drawing on the screen, for example, the window server will ignore messages from it. If it doesn't have the bit required to dial phone numbers, the network server will refuse dial instructions from it.
Like other servers, the file server checks capability bits before allowing a process to write to or read from the filesystem. Every program gets a private directory that it can use at will; however, by default, it cannot access the rest of the filesystem. This is how executable files are protected, for example. Only processes with the TCB capability can write to the \sys directory. All executables are stored in \sys\bin, and can be modified only by code in the TCB, such as the installer.