WACS: Security Configuration

Contents

WACS login system

 Although technically a web-based application, wacslogin will be dealt with here in security instead because it is more appropriate. If you only plan access control based upon static IP addresses, you just need to register those addresses and their users in the access control list below. Assign them as type permanent and you should never be asked for a password. However, if you want any kind of off-site access or conditional access, then read on. At it's simplest, wacslogin profers a simple login screen requesting username and password; when given, if they are correct, Wacs will prompt for age consent and exclusion preferences before adding the calling host to the access control list with the appropriate parameters and then redirecting to the Wacs home page.

However checking a user name and password combination on a Unix/Linux box is a potentially very complex activity as the authentication could potentially be handled by any number of bizzarely named methods: NIS, passwd, SMB, LDAP, and Kerberos, to name just a few. Fortunately there is a sub-system that protects you from much of the complexity called PAM - Plugable Authentication Modules. Unfortunately, there doesn't seem by default to be a service that gives us the extent of freedom needed to authenticate a user "out of the box" - the main limitation being that the process needs to be running as the user themselves or as the superuser in order to authenticate that user. Since the Wacs login application is running as a normal user (apache - the web server owner), it doesn't have those rights unless we create a new PAM "service" file that allows it. So, we need to create the service file, which is called simply "wacs" in the /etc/pam.d directory. 

#%PAM-1.0
auth    required        pam_stack.so service=system-auth

The modes (date not important) on this file need to be: 
-rw-r--r-- 1 root root 67 Oct 17 17:55 /etc/pam.d/wacs
These steps are sufficient for most authentication methods to then work normally; NIS, LDAP, etc.

Unfortunately there is one exception, the most common method of all used by most default installs of Linux, the /etc/passwd and /etc/shadow combination. In this the information on the user accounts is in /etc/passwd as on a normal Unix system, but the encrypted passwords are placed in a separate file, /etc/shadow, that is normally only readable by the system superuser or processes running with that priviledge. When building Wacs, we had to take a decision between running our login process as the system superuser or modifying the permissions so that the web server process could read the encrypted form of the password. We choose the later option as we felt it was the lesser of two evils. You do have to be aware that this modification is non-standard, may well get over-written and does represent a small reduction in the strength of the system security. That said, normal users of the system are still unable to read the encrypted password as the shadow mechanism intends, and the password form available to the web user is still the subject of a pretty serious one way encryption algorythmn. It is still less exposed than it can be when using many of the other authentication methods like NIS, SMB, etc. The steps to make this change are: 

# chgrp apache /etc/shadow
# chmod g+r /etc/shadow
#

Once this is done, wacslogin should be able to log any registered user into the Wacs system with their own password. Note that if you wish any specific user to be barred, you can specify that in the barredusers directive in the main Wacs configuration file.

One further note if you are running a Linux distribution with the Security Enhanced Linux (selinux) enabled, typically Fedora Core or RHEL linuxes. (You can find this out by typing sestatus and if the Current Mode reports as enforcing, this is enabled.) For these distributions, you will need to take a couple of extra steps to make sure that the WACS system can read it's lease files. In a nutshell, you need to do the following: 

# chcon system_u:object_r:httpd_sys_content_t /var/run/wacs
# chcon -R system_u:object_r:httpd_sys_content_t /var/run/wacs/*
#

Access Control List

 In the same directory as the WACS configuration file (typically one of /etc/wacs.d, /usr/local/etc/wacs.d or /opt/wacs/etc), there needs to be a second configuration file wacs.acl, this one controlling access to the system. Once again this configuration is in XML, a sample file would look like: 
<?xml version='1.0' standalone='yes'?>
<accesslist>
 <ipv4-192.168.1.15>
  <user>johnd</user>
  <type>permanent</type>
  <date></date>
  <role>admin</role>
  <prefexcl>C,F</prefexcl>
 </ipv4-192.168.1.15>

 <ipv4-192.168.1.17>
  <user>billw</user>
  <type>permanent</type>
  <date></date>
  <role>power</role>
  <prefexcl>C,F</prefexcl>
 </ipv4-192.168.1.17>
</accesslist>
Each section of the file is enclosed by a <ipv4-host_IP> and the entries within apply to that host address only. The first one, user, gives the user name to attribute accesses from this host to. The second attribute, type, is either permanent or lease. If it is permanent, access will always be granted as user. If it is lease, access will be granted until the time/date given in this field (in unix seconds since epoch date format). The role field defines what level of access this user should be given to make modifications to the database. While code to use this is only partially implemented, plans are for it to be admin, power or viewer - at present the tag set manipulation apps do not allow viewers to delete tag sets or their members. Admin will be allowed to do anything, power can rate sets, and viewer can only look and search. The final option prefexcl allows apps like wacsmodelpage and wacsmpthumbs (see the description here) to hide the sets of types you don't like to see; for example straight sex if you're not into looking at that. What is expected here is a comma separated list of scatflag values which are to be excluded, so for instance if you don't want to see Straight (F) or Group Orgy (G) sets, this should be set to <prefexcl>F,G</prefexcl>

There is one magic entry, <ipv4-all> which can be added to disable the access control system entirely. Note that the username must not be "nobody" as that indicates failure. An entry for this would look like: 

 <ipv4-all>
  <user>wacs</user>
  <type>permanent</type>
  <role>viewer</type>
  <prefexcl></prefexcl>
 </ipv4-all>
and would allow viewer access to all people who can reach your web server. If you have no inbound access from the internet, it might be OK to do this.
Next Section: Management Tools
Back to WACS Documentation Index