Introduction
  Installing
  Handling
  Virtual servers
  Modules
  Filesystems
  RXML tags
  Graphics
  Proxy
  Miscellaneous modules
  Security considerations
    Challenger user
    Restricted pages
    Trust levels
  Scripting
  Databases
  LDAP
  FrontPage
  Upgrading
  Third party extensions
  Portability
  Reporting bugs
  Appendix
 
Challenger user

A question you should ask yourself when installing Challenger, is whether to run Challenger as a normal user, with limited system privileges or, as the superuser, with unlimited system privileges. Server processes are traditionally run as superuser since a server usually has to perform some tasks that need superuser privileges. Servers run by the superuser are usually easier to run and maintain but they also have the potential of becoming more serious security hazards since an attacker, who gains access to such a server, will have access to more or less the entire system.

Challenger is no exception. It needs superuser privileges for essentially two tasks, opening privileged ports and starting CGI scripts as the user who owns the script. Challenger is written to be able to run as superuser securely, but here, the configurability and extensibility can be problematic. If the server is configured the wrong way, any user who can write web pages can break into the server. Extensions to Challenger that are not written with security in mind might even make it possible for outsiders to break into the server.

So lets take a closer look at the two reasons why Challenger needs to be superuser and how Challenger can be run without being superuser.

Privileged ports
The default ports for HTTP, 80, HTTPS, 443 and FTP, 21 are all privileged. That means that only the superuser can open them. If Challenger is to use the privileged ports, which is necessary for it to handle a normal web site, Challenger needs to have superuser privileges when opening the ports.

CGI scripts
Challenger has the option of running a CGI script as the user it belongs to. This can only be done if Challenger has the privilege to start processes as another user, a privilege that belongs to the superuser only.

Running as a normal user
There are three ways of running Challenger as a normal user. It can simply be started as that user, it can switch to that user temporarily, or it can switch to that user permanently. Switching to another user is controlled by the Global Variables/Change uid and gid to and Global Variables/Change uid and gid permanently variables.

Starting as a normal user
Starting as a normal user is the safest way, since Challenger then won't run for a single second with superuser privileges. Unfortunately, this also means that Challenger has no way of opening the privileged ports, and another program will have to do this and relay the ports to Challenger. Incidentally that other program could be a Challenger using the HTTP Relay module.

Temporary changing to a normal user
If run in this mode Challenger will drop superuser privileges and switch to a normal user, but it will switch back to superuser when it needs to. This will improve security, but since the server still runs as superuser now and then, a malicious and expert user who breaks the security of the server may still gain superuser privileges. This option should not be used together with threading. Strange things happen to threaded programs that switch user.

Permanently changing to a normal user
With this option, Challenger will run as superuser until it has opened its ports, and then switch to a normal user with no possibility of switching back. Two consequences of this are that if you configure a new privileged port you have to restart the server for the change to take effect and that CGI scripts can only be run as the server's user.

All modules will be loaded while the server is still running as superuser. This means that you still have to trust all the modules you have enabled. It is also important that the Challenger user does not have permission to change the module or any file in server/. Nor should the server be able to change its configurations/Global_Variables file. The first is to ensure that an attacker cannot replace the server with her own program or module. The second is to ensure that an attacker can't change back the setting that makes the user change permanent.

Using simple front end
One way of having it all, both security and functionality, is to use a front end that opens the privileged port and then relays requests to a server running as a normal user. The front end could be a Challenger server using the HTTP Relay. It could as well be a simpler relay program, or maybe a dispatcher or router.