Cobalt Raq Servers And Cgiwrap

With the growing popularity of Cobalt's RaQ servers many designers on thelist are either hosting their sites on a RaQ or will be requested to do so by a client. There is a unique feature on a RaQ that few RaQ users are fully aware of, a feature that allows for radically changing a site's architecture.

Background

The RaQ3 & RaQ4 allow a hosting company to host up to 200 domains on the server. Out-of-the-box the RaQ is an Apache webserver running on a Linux RedHat6.2 O/S. The Cobalt GUI allows for server and site maintenance through the browser that completely eliminates the need for telnet access for anything other than the installation of unique Apache/RedHat modules. The ability to turn telnet off, and leave it off, is a major security enhancement since 99% of attacks assume commandline access.

The Problem

The Cobalt GUI is run by Perl scripts. Therefore, Perl on a RaQ must run as the user named "root" since the GUI must read/write configuration files owned by "root". This is unusual on an Apache server where Perl commonly runs as the user named "nobody", the same user that Apache runs as. If left this way any Perl script on the server could read/write config files such as httpd.conf and access.conf, opening server management to all users on the system.

On a standard installation Perl's activity is controlled by the "other" permissions set in the Unix permission format "owner-group-other". A Perl script commonly therefore has 711 permissions to execute and 666 permissions on a file to read/write that file. In both cases the controlling permission is the last one - ??1 and ??6.

CGIWrap to the rescue

CGIWrap, developed in 1997 by the legendary Nathan Neulinger, forces all Perl scripts to run with the permissions of the user who owns the script (7??). Suppose the siteAdmin is a user named "xyz". If "xyz" creates and therefore owns the script, the script can execute with only 700 permissions. Likewise that script can read/write any file owned by "xyz" that has 0600 permissions. In fact that script could read/write any file anywhere on the server that is owned by "xyz" and has 600 permissions, not just files in "xyz's" domain path. With that in mind, all users are exclusive on a RaQ, preventing "xyz" from existing twice and having files inside someone else's domain path.

CGIWrap solves the RaQ problem by allowing scripts owned by the user "root" to read/write config files owned by "root" with only 600 permissions. The 600 permissions of course prevents the user "xyz" from reading/writing such a config file. But the opposite is also true for "xyz", which changes how "xyz" might use Perl.

Advantages

Conventional wisdom dictates that files containing sensitive data should be located outside of the domain path, or within an htaccess controlled directory within the domain path. Either location makes such files inaccessible to the world through a browser. With CGIWrap, sensitive files can be given 600 permissions and be securely located anywhere inside the domain and still be readable/writable to scripts. Since browsers require at least ??4 permissions to read a file, 600 files are totally inaccessible to browsers or other world agents such as LWP and search robots. The same rule applies to directory access, a 700 directory will be fully accessible to a script and yet totally inaccessible to world agents. This form of security is actually superior to the conventional "hide the file" techniques since it relies on Unix's core kernel security feature, the user/permission structure. Being able to locate files securely within the domain path can radically alter a site's layout, especially if that site's main function is to deliver sensitive data to a subscriber base. The CGIWrap on a RaQ has been modified (modernfied) allowing scripts to live anywhere, not just inside an old fashioned cgi-bin. Scripts and the files they work with can therefore be located side-by-side making maintenance easier.