$Id: SECURITY,v 1.1 1998/06/16 21:25:23 chris Exp $
------------------------------------------------------------------------------

CGI Security
============

For this discussion, I will assume (for ease of explanations) the following:
	Vchkpw home directory:	/home/popusers
	Vchkpw user:		vpopmail (default)
	Vchkpw group:		vchkpw (default)
	CGI directory:		/usr/local/httpd/cgi-bin/vchkpw
	httpd runs as:		user nobody, group nogroup

1. vchkaccess
-------------
There is only one file that cares about who it is owned by. vchkaccess manages
the communication between the CGI and the password files, and is responsible
for modifying, deleting, updating and creating users and their directories.
As such, it must be able to write and read to any point under vchkpw's home
directory, /home/popusers.

In order that it keeps file ownerships and groups intact, vchkaccess should
be owned by user vpopmail, group vchkpw, and should be SUID, SGID. (SGID
isn't essential - it ensures that the group ownerships stay intact, but it
doesn't affect the operation of the CGI or of the vchkpw package).

Authentication of users and commands passed to it is via a cookie-style
mechanism. The cookies are discused in the next section.

2. Cookies and authentication
-----------------------------
Authentication is via domain/password pair - the password being that of the
postmaster for the domain. Unless SSL is used, all information that is passed
over the CGI in in plaintext.

When a postmaster has been authenticated successfully a cookie is created in
the directory /usr/local/httpd/cgi-bin/vchkpw/cookies. The permissions on the
directory should allow the CGI to write to it. There are two alternatives:
	- make the cookie directory 733 (rwx-wx-wx). This allows any user to
	  write to the directory, but not read the contents of the directory.
	  Hence, it is not possible for a user on the system to snoop on 
	  existing cookies, and fake an authorisation. The downside is that
	  the user could create their own cookie, as the directory is world
	  writable.
	- make the cookie directory 730 (rwx-wx---), and ensure the group
	  ownership of the directory allows the web server to write to it.
	  This prevents snoopers and also prevents a user creating a file
	  in the directory as a fake cookie.

Cookies in the directory are individual files, zero bytes in size, with the 
format of their names being:
	<timestamp>.<domain>-<remote-host>

So a cookie of 892765304.acme.cej.net-127.0.0.1 means:
	Time of cookie creation: 892765304
	Domain cookie is for: acme.cej.net
	The CGI is being ran via the host with IP: 127.0.0.1


3. Perl scripts
---------------
All the perl scripts should have permissions 755 or 750 (rwxr-xr-x, rwxr-x---).
These are ran as the user of the webserver. If 750 is given, then the scripts
should belong to the same group as the running webserver.


4. HTML Templates
-----------------
Should all be readable by the webserver (644 or 640).


5. Overview of permissions
--------------------------
The following is a list of possible permissions for the CGI. This isn't fixed.
Providing the web-server can access the HTML templates, perl scripts and 
write to the cookies directory, and providing that vchkaccess has full access
to modify vchkpw password files, any structure can be used.

File					Permissions		Ownership
--------------------------------------  ----------------------  ---------
/usr/local/httpd/cgi-bin/vchkpw		755	rwxr-xr-x	root.root
		|
		+-- cookies/		730	rwx-wx---	root.nogroup
		|
		+-- html/		750	rwxr-x---	root.nogroup
		|     |
		|     +-- *		640	rw-r-----	root.nogroup
		|
		+-- lib/		750	rwxr-x---	root.nogroup
		|     |
		|     +-- *		640	rwxr-x---	root.nogroup
		|
		+-- domains		750	rwxr-x---	root.nogroup
		|
		+-- vchkaccess		6711	rws--s--x	vpopmail.vchkpw
		|
		+-- vchkexpire		700	rwx------	root.root


6. Final thoughts
-----------------
If you are running on a secure system that has no real users, or a few trusted
users, then the paranoia for CGI is lessened, but isn't removed. Every care
has been taken to ensure that security isn't breached, but any user with a
shell account must be treated with care, as they are a potential threat.

The biggest problem with this CGI is the cookie authentication. If that is
breached, then the whole virtual domains system is under threat - however, it
can only be breached from a shell - if the user is going via the CGI, then
it is safe.

If anyone has any suggestions on how the authentication and/or security could
be improved, then please get in touch.

Chris Johnson, April 1998
sixie@nccnet.co.uk

------------------------------------------------------------------------------
