Introduction:

The world-wide-web (W3) services now in widespread use throughout the world present considerable risks both to the provider of such a service and to the user using these services.

The main risk to the user comes from the content of the information interpreted by their W3 client and the potential for servers to gather and exploit information resulting from client requests. Although these are very important areas of concern, they are not what this paper is about and they will be ignored throughout the remainder of this paper.

The main risk to providers of these services is that someone might be able to fool their server software into doing something it is not supposed to do, thus allowing an attacker to break into their server and do some harm. In recent months several such vulnerabilities have been found in commonly used server software, and historically, this has been the source of many security problems. This paper is about server software designed to prevent this sort of exploitation.

Basic Principles

In order to reduce the risks associated with servers of this sort while still providing a commercial presence for these services to the Internet community, organizations have taken many strategies, ranging from leasing space on provider systems to creating elaborate bastion hosts on network firewall systems to handle these services. The costs associated with these solutions is relatively high, primarily because of the added complexity of securely operating and maintaining systems set up in this way.

An alternative solution to the security problem with servers is to design a secure server with security properties that can be explicitly demonstrated. This is the approach we took with this daemon.

Desired Security Properties

The general properties of interest to us are (in order of highest to lowest priority):

• Information Integrity - We want to assure that the information residing on the server is not corrupted by the actions of outside users as a result of their use or abuse of the secure service.
• Availability of Service - We want to assure that outside users of the service cannot make the server unusable for other users as a result of their use or abuse of the secure service.
• Confidentiality - We want to assure that the service only provides information to outside users that is explicitly authorized for outside access.

We would also like to assure these properties to an even higher degree for information not explicitly designated for outside use than for information that is explicitly designated for outside use.