Check out the new USENIX Web site. next up previous
Next: SubOS-enabled Operating Systems Up: Building a Secure Web Browser Previous: Introduction

Motivation

  With the growth of the Internet, exchange of information over wide-area networks has become essential for users. Web browsers, like Netscape Navigator and Microsoft Internet explorer often automatically invoke helper application to handle the down-loaded object. In some cases, like in Perl scripts, they will query the user before executing it. In others, like in Postscript files or Java applets [10,15,9], they will execute the content, possibly compromising the security of the system. The former approach puts a lot of burden on the user, who more often than not is not particularly security conscious. In the latter case the user is bypassed altogether and system security becomes dependent on the correctness of the Postscript or Applet viewer.

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.


next up previous
Next: SubOS-enabled Operating Systems Up: Building a Secure Web Browser Previous: Introduction
Sotiris Ioannidis
4/28/2001