It is also the case that seemingly inactive objects like Web pages are very much active and potentially dangerous. One example is JavaScript [6]programs which are executed within the security context of the page with which they were down-loaded, and they have restricted access to other resources within the browser. Security flaws exist in certain Web browsers that permit JavaScript programs to monitor a user's browser activities beyond the security context of the page with which the program was down-loaded (CERT Advisory CA:97.20). It is obvious that such behavior automatically compromises the user's privacy and security.
The lack of flexibility in modern operating systems is one of the main reasons security is compromised. The UNIX operating system, in particular, violates the principle of least privilege. The principle of least privilege states that a process should have access to the smallest number of objects necessary to accomplish a given task. UNIX only supports two privilege levels: ``root'' and ``any user''.
To overcome this shortcoming, UNIX, can grant temporary privileges, namely setuid(2) (set user id) and setgid(2) (set group id). These commands allow a program's user to gain the access rights of the program's owner. However, special care must be taken any time these primitives are used, and as experience has shown a lack of sufficient caution is often exploited [13].
Another technique used by UNIX is to change the apparent root of the file system using chroot(2). This causes the root of a file system hierarchy visible to a process to be replaced by a subdirectory. One such application is the ftpd(8) daemon; it has full rights in a safe subdirectory, but it cannot access anything beyond that. This approach, however, is very limiting, and in the particular example commands such as ls(1) become unreachable and have to be replicated.
These mechanisms are inadequate to handle the complex security needs of today's applications. This forces a lot of access control and validity decisions to user-level software that runs with the full privileges of the invoking user. To overcome these shortcomings applications such as Web browsers become responsible for accepting requests, granting permissions and managing resources. All this is what is traditionally done by operating systems. Web browsers consequently, because of their complexity as well as the lack of flexibility in the underlying security mechanisms, possess a number of security holes. Examples of such problems are numerous, e.g. JavaScript, malicious Postscript documents, etc.
We wish to demonstrate how to build a secure browser, designed to handle attacks by incoming malicious objects, on top of an an operating system that offers process-specific protection mechanisms.