WACS: Security Configuration

Contents

• WACS login system
• WACS logout command
• WACS Preferences Tool
• Access Control List
• ACL Overview
• prefexcl - the exclusions mechanism
• usedirect - the usedirect mechanism
• optional parameters - preferences

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

-rw-r--r-- 1 root root 67 Oct 17 17:55 /etc/pam.d/wacs

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/*
#

<?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>
  <usedirect>yes</usedirect>
 </ipv4-192.168.1.15>

 <ipv4-192.168.1.17>
  <user>billw</user>
  <type>permanent</type>
  <date></date>
  <role>power</role>
  <prefexcl>D,B,C,F</prefexcl>
  <usedirect>no</usedirect>
 </ipv4-192.168.1.17>
</accesslist>

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>

However doing this moves the set icon outside of the access control afforded by Wacs, so technically it is unprotected - if you're using the security mechanism to restrict content from spouses or minors, this is really bad. If you're using the security mechanism in a subscription web server, people being able to get to a single 120 x 120 pixel thumbnail of each of the sets you have, but not the set itself, is probably of no concern at all. Also remember that if no web page contains a reference to it, people are unlikely to find the thumbnail's full URL unless they have access to your web browsers history, cache or a corporate firewall log. Remember that wacs normally invokes icons via a fairly anonymous call to wacsimg with a set number as an argument - this would not normally trigger any automatic corporate firewall content flagging systems and such a URL is only valid from the authenticated host itself during the time period of the lease. A future option should allow voluntary relinquishment of a lease ahead of it's expiry time, making this even safer. Other addresses would not be able to display it, nor would the URL be any use after the expiry of the lease. When usedirect is used, the name is obvious, permanent and accessible - it might well trigger corporate firewall content flaggers. WACS can be simultaneously used in both ways - you could use usedirect when at home, and normal access methods when elsewhere. The consequences of using it elsewhere do of course fall on your head - the above comments about corporate firewalls are informational only and in time, who knows, some rulesets may be updated to specifically detect wacs usage.

To enable usedirect operation, you need to ensure that the fsloc section configuration options seticons, officons, vidicons, dvdicons and addicons all point to locations within the web server document tree (ie /var/www/html or similar). The generate command will re-create the auto-generated icons under seticons; the others will have to be moved (or copied) from their previous locations. From this point on, the icons should someone know the URL by some means, will be accessible to all (unless you restrict them again through the web servers access control mechanism). To enable usedirect functionality, you then add the URL of the web server icon directory to the configuration file.

optional parameters - preferences