This document provides an overview of how Jeeves helps you to provide a secure web site, and discusses each of the key mechanisms provided in the current release.

• What Website Security Should Mean to You
• Current Release Features

NOTE: The Jeeves Alpha2 release is not intended to be a secure web server release. In particular, there is no "servlet sandbox", and a number of operational security issues have not yet been addressed. Please report any security problems you uncover to the support alias listed at the bottom of this page.

---

What Website Security Should Mean to You

Services shared by many people need to defend against a variety of problems. The solutions to these problems are often lumped together as "security". One of the most effective ways to understand what this "security "does for you is to describe the kinds of threats or attacks your website can defend against.

At a high level, Jeeves allows you to defend your website against these (and other) kinds of attacks:

• Theft or Alteration of Data ... By providing classic identity based access controls, and in conjunction with physical and operating system protections, Jeeves lets website administrators control who can get data (and who can't). The data which is protected includes both web pages and the website's administrative data.
• Malicious Code ... By restricting the servlet code which can run, and the "sandbox" environment in which it runs, Jeeves lets website administrators control the damage that malicious code can cause.
• Eavesdroppers ... Even when your website itself is secure, users of your site need to be concerned that their data (e.g. financial or other highly sensitive data) is not misappropriated when it is being sent to (or retrieved from) the server.

Your Site's Security Policy

Each website has a security policy which defines "how secure this site needs to be". (Sometimes it's not very well articulated!) A security policy talks about more than just "how to secure this website". It also talks about the kinds of risks that are acceptable, and those which are not. There will always be risks that you deem to be acceptable. Consider your home: just how determined must a burglar be to get access and steal your silverware? Many people don't defend against burglars willing to break windows to get in. Even among those which defend against such burglars, not everyone needs the same degree of paranoia. The same kind of "risk versus reward" tradeoffs need to be made on your website too.

Your Website Administrator

Your security policy is implemented by your website administrator. He (or she) uses the web server software and other tools such as operating system security, and physical security controlling access to the server and to its backup media. Your site (the service provider, and its users) needs to trust the administrator, host system, and the web server software to maintain your security policy. Un-trustworthy staff is the number one security risk in any organization. You can never trust only software mechanisms, since they can be overridden. Your staff also need to be trustworthy.

Jeeves can't help you find a website administrator that you can trust not to violate your security (or that of your clients). Nor can Jeeves help you keep users from being given more trust than they really deserve, or help you choose an operating system that's worthy of your trust. However, we do provide a number of mechanisms that a trusted administrator can use to secure your site against common website security threats.

---

Current Release Features

HTTP-Oriented Support

The HTTP protocol provides a number of security features which almost any web server will support in some manner.

• Basic Authentication ... Authentication involves a user entering a user name and a passphrase, for example into a login prompt or (in a graphical user interface) a dialog box. HTTP defines "Basic Authentication". To get access to a particular web page, you must authenticate and then pass an access control check. Jeeves supports this "Basic" authentication scheme, using Access Control Lists (described later) to control access. However, there are two well recognized problems with this standard HTTP mechanism:
  • "Basic" authentication sends the password over the network, effectively in "cleartext" so that any eavesdropper can determine the right password to use. (Both "Digest" authentication, described below, and SSL client authentication, not yet supported, protect against this attack.)
  • A closely related problem is that the server needs to store the passwords in cleartext; they are "shared secrets". This means that when (not if!) a server is broken into, the attacker gains the right to authenticate as each user. Since users frequently use the same passwords at many different sites, this is a threat against both those users and all those other sites. (SSL Client authentication is used to protect against this kind of attack.)
• Digest Authentication ... As noted above, there are two significant problems with "Basic Authentication" in HTTP. The "plaintext passwords on the network" problem is resolved with "Digest" authentication; although the password must be known to the server, it is not sent over the network, so that an eavesdropper can read it. However, the server must still know the client's password; the client, and other servers, are still at high risk when the server is successfully attacked. (SSL Client authentication protects against such attacks, but is not yet supported.)
• SSL Server Authentication ... Users need to have a way to trust that the server to which they send information -- such as a credit card -- is really the server they think it is. SSL always authenticates the server to the user of a browser; HTTPS URLS (which use SSL) let users know that the server they're talking to is who they think it is. This is usually done with the assistance of some third party Certificate Authority, which provides a clearly defined level of support for a guarantee that the server is who it says it is.
• SSL Eavesdropping Protection ... Another feature of the HTTPS protocol is that, when allowed by both the web site administrator and by the client using a web browser, all data sent to or from the server can be encrypted to allow private communications. This means that an eavesdropper can't learn potentially sensitive information about your personal finances, or your love life.
• Realms with Users and Groups ... When you have many users, you need to group them for two reasons. Both are supported in Jeeves:
  • You need to create different realms for different sites, e.g. different virtual hosts, or parts of a given website serving different applications. Users named "dave" in two different realms are actually two different identities, and will be given two different sets of access privileges.
  • You need to create groups of different users (within a given realm) so that you can extend access privileges more efficiently than listing the users one by one. For example, you might want to define a group "admins", all of whom can access administrative web pages.
• ACLs Protect Web Pages ... Jeeves provides "Access Control Lists" (ACLS) to let your website's administrator control which users get access to individual web pages or trees of such pages. ACLs may also be used by servlets.

Jeeves-Specific Features

Jeeves offers a number of features beyond those minimal ones supported by almost any web server:

• Simple Administration ... Although it is not always recognized, having good tools to handle administration tasks is an advantage in terms of security. The reason is that manual administration (for example, editing any kind of text files by hand) is extremely error prone, and errors invariably reduce security. Jeeves provides administrative tools which help avoid common administration errors.
• Secured Administration ... By default, the Jeeves administration pages are controlled through HTTP's new "Digest Authentication". In addition, these pages may be accessed through "HTTPS", so that the administrative operations are protected from certain "active wiretapper" attacks and may be kept private.
• Non-root UID/GID (UNIX ONLY) ... UNIX only allows "root" to bind to the default HTTP server TCP port (80). This means web servers often need to start up as root, just so they can bind to that port. However, letting complex programs run as "root" is generally perceived to be a big security risk, so most sites prefer not to allow this. Jeeves allows you to control which UNIX user ID to use after your server binds to that TCP port. This lets you run Jeeves as your default server, without worries that a malicious servlet can commit some of the mayhem that only "root" should be allowed perform. In fact, Jeeves can be set up so that the "root" account is needed only when initially setting up Jeeves, and all normal administrative tasks can be done without needing "root" privileges.