Caucus and Security

Last revised: 23 October 2004

There are four areas to consider when evaluating the security of a Caucus installation.  This document summarizes the security features and concerns for each area.

  1. Server-side
    This covers all of the security aspects of the server on which Caucus is installed.

    1. The actual server.  Securing a unix/linux server is beyond the scope of this document; however, for a good general guide, see Building Secure Servers with Linux.

      One of the most important general principles is to make sure you keep the server software up to date.  Most unix/linux companies provide automatic means for doing so.

      The web-server software on the server must be configured to disallow "indexing", meaning that outside users are not allowed to see an index (directory listing) of any directory or folder exposed to the web.  Otherwise people may wander through the tree of uploaded Caucus files (see IV.4 below) at will.

    2. Caucus installation.  Caucus must have its own, dedicated, userid and group.  Access to this id must be carefully controlled, basically meaning that the 'root' id and the caucus id must only be useable by trusted people.  (This also means that Caucus may be installed multiple times on a single server.  Each Caucus site is completely separate, with its own set of programs and data files, as if they were on physically distinct servers.)

      The files that contain Caucus conversations and data are kept as plaintext, unencrypted, accessible only to the caucus id.  This means that anyone who can access the files can read any of the conversations.  (Future versions of the software may offer data-level encryption, which would provide some additional protection even if the root or caucus ids are compromised.)

      Some Caucus data is also kept in a MySQL database.  Again, Caucus requires its own separate database, with its own userid and password, for maximum security.

      Caucus uses the unix "setuid" permission on the binary software (compiled 'C' code) to access these files.  It does not run as setuid-root, as this is commonly considered to be "a bad thing".  Instead, it runs setuid to the caucus id, which is safe.

  2. Network security
    When Caucus is installed, it offers the option to use either the plain "http" protocol (the default), or "https", otherwise known as SSL. 

    Under plain http, all data passes over the network as plaintext; in theory it would be possible to read data, userids, and passwords via a network "sniffer".  (Although in practice this is difficult unless the sniffer is connected to the local area of either the server or the end-user.)

    By using https with SSL, all data passing over the network to and from Caucus is securely encrypted.  This requires some additional setup, however, in the form of purchasing and validating a site certificate from a registered certificate authority.  It also means that Caucus pages may appear to load somewhat slower.

    All Caucus data passes through either the http or https protocols.  The only exception is the optional 'chat' module, which uses a different network port, and is unencrypted.

  3. Client-side
    1. Userids.  Each Caucus user is identified by a userid and a password.  The user must enter both in order to be identified by Caucus, and all of their actions within Caucus are tracked by that userid.

      There are two ways in which users can login to Caucus.  One or the other (or both) may be configured when Caucus is installed, or modified later.

      1. Cookie-based.  This is the default login method.  Users enter their userid and password at an HTML page, which generates a session (not a disk!) cookie.  Caucus uses that cookie to verify the user's id on each Caucus page load.  For further technical details, see Caucus Cookie Logins.

      2. Web-server based.  The actual login is handled by the web server, which passes the userid on to Caucus.  Advantage: this method avoids using cookies.  Disadvantage: the userid and password information is cached in the browser, and remains there until the browser is completely closed.  This is a bad idea for any public PC.

      Caucus also supports several different authentication sources.  For the cookie login method, the actual userid and password information may be validated against:

      • A "flat" passwd-style file, containing only encrypted passwords
      • An LDAP database
      • Any other (custom) method that can be accessed via the Caucus authentication API.  Essentially, you can write a small program that Caucus calls to get or set userids and passwords.

      For the web-server based login method, only the passwd-style source is supported "out of the box".  However, most web servers can be configured to authenticate against a variety of sources.

      Note that Caucus never stores unencrypted passwords on disk.  Unencrypted passwords may remain in memory (RAM) for the duration of a user's session, except as noted in III.1.b.

    2. Browsers.  Caucus supports a wide variety of browsers, including:
      • Internet Explorer 5.01 and higher
      • Netscape 5 and higher
      • Netscape 4 (with loss of advanced functions)
      • Mozilla 1.3 and higher, or any version of FireFox.
      • Safari

      Given the history of security problems with Internet Explorer, we recommend Mozilla for the best combination of features and security.

    3. Pop-ups.  Caucus uses pop-up windows for certain features; users' browsers must allow (enable) certain kinds of pop-ups.  (Specifically, they must allow pop-ups either for the Caucus site, or pop-ups that are activated by user action, e.g. clicking a link.)

  4. Inside Caucus
    This covers the security model inside Caucus, i.e. those Caucus features that relate to normal day-to-day use of Caucus.

    1. User Roles.  Within Caucus, users are assigned distinct roles: managers, organizers, and ordinary users.  Managers are assigned specific abilities; not all managers will have all abilities.  One person is designated the "primary" manager, which has all abilities.  Only the primary manager may change the passwords of other managers.

      Organizers (aka facilitators) control the content and membership of specific conferences, see below.

    2. Conferences (aka discussion rooms) are content and discussion areas, with restricted memberships.  Organizers control who may "join" or see a conference, what goes on in the conference, and what kind of content it may contain (even to the level of filtering out specific HTML tags in content).

    3. Uploaded Files.  Users may upload files into Caucus conferences or file library areas.  However, these files are protected only by the obscurity of the the URLS where they are located.  A knowledgeable user, who knows the name of an uploaded file, may be able to find it, even if they are not allowed in the conference where it was uploaded.

    4. Virus scanner.  Caucus can run any server-side virus scanner automatically against all uploaded files.  We recommend the product f-sav, from

    5. Email Participation.  Caucus can also be configured to act somewhat like a "listserv", in that users who cannot access the web interface for some reason may still participate (read and write) in a conference via email.

      This option should be used carefully with sensitive conferences, since once something is sent via email, it has "escaped" the enclosing secure Caucus environment.

    6. Password options.  Caucus can be configured with several options that relate to the control of passwords, including:
      • Requiring that passwords not be identical to userids.
      • Allowing users who have forgotten their passwords to reset them securely, via email.