Skip to content

SASL Configuration

Simple Application and Security Layer

SASL (Simple Application and Security Layer) is the method used to secure data in LSMCD and Memcached. There are various subtle differences in configuration between the two. This section describes the configuration you need to perform to allow LSMCD to operate in a SASL environment.

Enabling SASL is database wide. Once SASL is enabled, all non-SASL databases will need to be regenerated. This is only necessary if you ran LSMCD without SASL. Regeneration is done by deleting the files stored in the Cached.ShmDir parameter of your node.conf file (default /dev/shm/lsmcd) and allow them to be recreated. You will also need to regenerate your databases if you wish to remove SASL.

You can also secure data by user using SASL. See SASL User Data for details.

As for Memcached, if you enable SASL, text telnet commands will no longer work as there is no security mechanism in telnet (unless you have the anonmous user enabled, see Anonymous User below). The memcached client test program memcapable will fail all tests as it does not properly handle SASL. If you wish to use this program to validate functionality, a customized version of the program is available in the distribution and can be built using instructions specified in the README.

If you are using cPanel you must perform initial configuration as described here. But new users and other functions can be performed using the LSMCD cPanel plugin described with the other cPanel features.

Configuring SASL

There are a number steps to configuring LSMCD to operate with SASL:

  • Enable SASL in your node.conf file.
  • Create and configure a user database.
  • Configure any additional settings needed for PHP or Python.

Enable SASL in Your Configuration File

This is discussed in LSCMD Configuration, which also discusses overall configuration.

In particular you need to specify in your node.conf file: 

CACHED.USESASL=TRUE

Note that once SASL is enabled, all failed accesses to Memcached functions are going to result in an error being written to the lsmcd log (the log defaults to /tmp/lsmcd.log). As mentioned above, ASCII and telnet commands are also going to fail as well (unless you have the Anonymous User enabled).

When you change this value, accesses to the existing LSMCD database will fail as the system will detect a mismatch between your prior SASL configuration and your current one. You will need to delete your LSMCD data files (as root): 

rm -rf /dev/shm/lsmcd

Create and Configure a User Database

A user database is required. The recommended method uses Cyrus SASL to create a sasldb managed database. Note that you become the security administrator for these accounts.

A sasldb database is typically stored in /etc/sasldb2 and is managed using the saslpasswd2 program. You must be root to manage users with saslpasswd2.

To create a user named user1 enter: 

sudo saslpasswd2 user1
You will be prompted for the password twice for that user. That information will then need to be coded in your memcached program. Details on the use of saslpasswd2 can be found in numerous places on the internet including saslpasswd.

You can use either the simple user name or the realm qualified name visible in sasldblistusers2 (the name with the @hostname appended to it). Note that for user managed data it will use the name specified (which means the realm qualified and unqualified names will be separate).

Creating a User Database Just for LSMCD

The sasldb database must have permissions which allow the LSMCD user read access to it (typically 640 in most environments). Since this allows read access to any user in the root group, this may not meet your security requirements. This can be circumvented by creating a SASL managed database which is accessible only to the LSMCD user.

As above you will use the saslpasswd2 program. However, specify a database name with the -f parameter. For example, to create a user user1 in the /etc/sasllsmcd database specify:

sudo saslpasswd2 -f /etc/sasllsmcd user1

Then you will want to make the database owned by the LSMCD user (nobody by default) and accessible only to that user:

sudo chown nobody:nobody /etc/sasllsmcd
sudo chmod 600 /etc/sasllsmcd

The program sasllistusers2 also supports the -f option.

To let LSMCD know of the database edit your /usr/local/lsmcd/conf/node.conf file and add the parameter: Cached.SaslDB. Assuming that the name of your new database is /etc/sasllsmcd add to node.conf: 

Cached.SaslDB=/etc/sasllsmcd

Configure for PHP

The procedures for the Memcached extension to PHP are documented at memcached.setup. You know you have it right if phpinfo displays a Memcached section.

The following is a sample PHP script you could create (named memcached.php) to validate that LSMCD is correctly installed and configured to work with SASL. You'll need to place it in the HTML directory of your server and adjust the user/password and other settings for your environment.

Some notes for all programming environments

  • You must instantiate an instance of the Memcached object (Memcache no longer works).
  • You must use the binary protocol (must be the first Memcached method).
  • You must turn off compression.
  • You must make the call to set the SASL authentication information (user/password) before you add the server.
  • Once you add the server successfully, you can perform all standard Memcached operations (get, put, getStats, etc.).
<?php
$mem_var = new Memcached();
$mem_var->setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$mem_var->setOption(Memcached::OPT_COMPRESSION, false);
$mem_var->setSaslAuthData('user', 'password');
$mem_var->addServer("127.0.0.1", 11211);
$response = $mem_var->get("SampleKey");
if ($response) {
 echo "get(SampleKey) => " . $response;
} else if ($mem_var->getResultCode() == Memcached::RES_NOTFOUND) {
 echo "Adding a key/value: SampleKey/SampleValue";
 $mem_var->set("SampleKey", "SampleValue") or 
 die("SampleKey Couldn't be Created: '( " . $mem_var->getResultMessage() . 
   " )' ");
} else die ("Error in get: " . $mem_var->getResultCode() . ": " . 
      $mem_var->getResultMessage());
?>

Start LiteSpeed and LSMCD and point your browser to the web page you created. If the user or password are incorrect you'll see a message like Error in get: 41: AUTHENTICATION FAILURE. However if you have it right you'll see the first time you access the page Adding a key/value: SampleKey/SampleValue and subsequent accesses will show get(SampleKey) => SampleValue.

If you do not use the $mem_var->setSaslAuthData('user', 'password'); line, then this example will work for non-SASL environments as well.

Configure for Python

There are a number of external classes for Python access to memcached. However, only the Python Binary Memcached client has been certified by LiteSpeed to work with LSMCD in SASL mode. Installation and use is fully described on their web site.

Secure User Data

This section discusses a feature of LSMCD which is not available in traditional Memcached: separation of individual users' data. This means that data saved by one user is not visible to any other users. In Memcached and traditional LSMCD, any data stored is available to all users (all authorized users if you have SASL enabled), which allows fast population of the cache and high utilization. However, it is insecure and thus can't be used to cache any data which is deemed to be sensitive to a specific user.

This new option allows data to be available to only the user authorized to access it. Thus the advantages of Memcached performance becomes available to sensitive data.

Enabling SASL user protection is database wide. Once SASL user protection is enabled, all non-SASL user protected databases will need to be regenerated. You will also need to regenerate your databases (the files stored in the Cached.ShmDir parameter of your node.conf file) if you wish to remove SASL or SASL user protection.

There is a user interface for CloudLinux/cPanel. Installation and use is described in the cPanel documentation section of this manual.

Configuration

To enable separating data by users, you need to specify in your node.conf file: 

Cached.DataByUser=true

As mentioned above, once you have made this change you must delete your existing databases or LSMCD will refuse to come up, as it will notice the changed data condition. You do this as root: 

rm -rf /dev/shm/lsmcd

The default is false so that data created by all users is visible to all users. Once it is set to true, each user's data can only be visible to that user. Note that you must enable SASL to enable DataByUser.

Use

LSMCD can be used once configured and activated using the traditional Memcached protocols and user commands. However, any data visible will only be visible to the authenticated user that created it. This means that the same data may be stored multiple times for separate users, but each user will only see the data created by that user. Expiration and deletion will again by based on the criteria set when the user created the data or on the parameters for the system as a whole.

You can also use the Cached.MemMaxSz parameter to have the cache begin aging out data when it reaches your specified size.

If you specify a realm qualified name (a name with a @hostname suffix) in your application, then that name will be used for storage. If you then specify a non-realm qualified name then the unqualified name will be resolved as a different name. This is so that names that appear different are handled differently.

Each user is designated a slice and all traffic will be sent to that slice. However, the size of the hash is determined globally for all users. So Cached.MemMaxSz sets the value where data ages out for all users based on a least-recently-used algorithm.

Anonymous User

To support the use of code that does not include authentication information (old code or code which wishes to use the facility but does not wish to deal with authentication), you can allow unauthenticated (anonymous) users to create and access data on your server that is distinct and separate from that created by authenticated users.

To enable separating data by users, you need to specify in your node.conf file: 

Cached.Anonymous=true

This does not create a security hole as the data stored and accessed by unauthenticated users is totally separate from data stored for authenticated users when Cached.DataByUser is enabled.

The default is false so that you do not mistakenly allow unauthenticated users access to Memcached facilities (even though the data would be separated).

Once the anonymous user is enabled, ASCII use is permitted, even though SASL may be enabled. This is to allow ASCII only applications to continue to use lsmcd. This includes telnet access. Again, if you have Cached.DataByUser enabled this does not open a security hole for secured access, as data sent in binary secured with a user/password is stored separately from anonmous data. However, if you do not have Cached.DataByUser enabled, this option is not recommended.