Author: Kevin J. Price (kjprice@ncsa.uiuc.edu)

Last Update: January 2, 2007

Restricting Community Accounts using the Communty Shell (commsh)

Introduction

Overview

The Community Shell (commsh) application represents a means of securing shared, community accounts at the resource level. This document serves as a guide for resource administrators seeking to implement the Community Shell on their resources.

The first section, 'Installation', details basic installation and configuration of the Community Shell.

The second section, 'Administation', details usage of administrative accounts to manage each community.

Background

A growing trend in supercomputing is the use of community gateways that provide superocmputing resources to a wider audience. These gateways typically operate off of a single, community account at the resource level. This account is thusly a shared account, as it is used by all users of the gateway.

Shared accounts represent a potential security problem. Specifically, if the gateway server is compromised, the account can be used to execute malicious code on end resources with a much greater degree of anonimity. The goal of the Community Shell is to mitigate this potential for abuse by placing restrictions on the applications that may be run by a community account.

To this end, a configuration file is created for each shared account that explicitly lists which applications (commands) the account can run. It can further specity the form of the parameters (arguments) passed to those applications.

In a typical scenario, this file will establish a directory for applications used by the community. Any applications within this single directory will be allowed, and applications outside of this directory will be restricted. Applications can then be added to or removed from this directroy as needed.

However, it is important that the community acocunt itself does not have access to modify the contents of this directory. If the account can upload scripts into this applications directory, it can execute arbitrary code on the system and thereby circumvent this security precaution. In order to prevent this form of abuse, it is recommended that a second, community administrator account be establish for each community.

This community administrator account is then used by the community administrators to manage which applications the community account can run. It should have its own set of credentials (password or private key) that are separate from the community account's. The administrator account credentials should not be stored on the same server as the community account credentials, so that a compromise of the community gateway server will not compromise the administrative account.

It should be noted that this community administrator method is only our suggested method of managing community accounts. There are other feasible methods, including group-based access or having the resource administrator manage each account directly. Which method makes the most sense for a given resource should be determined by the resource administrator.

Installation

This section explains how to install and configure the Community Shell (commsh) to restrict community accounts under a UNIX-like system.

Prerequisites

In order to build and install commsh, you will need the following software installed:

GNU Make
A standards-compliant C++ compiler (gcc3 preferred)
Sed

In order to make use of the GRAM functionality, you will need:

a fully configured GRAM installation or a GT4.x installation
GNU Patch (or compatibel)

Installation of commsh

A source tarball of the most recent version of commsh can be downloaded from:

http://security.ncsa.uiuc.edu/research/commaccts/downloads/

You will need at least version 0.1.3b for GRAM support (see below).

After downloading and unpacking the tarball, the package can be built using:

./configure
gmake
gmake install

You can control where the package is installed by passing arguments to ./configure. For a full list of options, see:

./configure --help

It is especially important to configure the final location of the configuration file, as this location is hard-coded into the executable binary and cannot be changed without recompiling.

Configuration

For a full list of configuration directives, see:

man commsh.conf

To configure basic command-access restrictions for several community accounts, the easiest way is to create a configuration file for each account, and then load these configuration files from commsh.conf based on the current user. An example configuration: (comments in blue)

/usr/local/etc/commsh.conf:

# Allow all users to run commands through commsh
AllowUser *

# Community User 1 (commuser1)
# Check GRAM job submissions by this user, assuming GRAM support is enabled
CheckUser commuser1
# Load an external configuration file for this user
ReadUserConfig commuser1 /usr/local/etc/commsh.d/commuser1.conf

# Community User 2 (commuser2)
# Check GRAM job submissions by this user, assuming GRAM support is enabled
CheckUser commuser2
# Load an external configuration file for this user
ReadUserConfig commuser2 /usr/local/etc/commsh.d/commuser2.conf

/usr/local/etc/commsh.d/commuser1.conf:

# Allow commuser1 to run any command in /opt/communities/bin/commuser1 with any parameters
DirectAccess /opt/communities/bin/commuser1/* **
# Allow commuser1 to create new directories and delete any files in /home/commuser1/shared/
DirectAccess /bin/mkdir /home/commuser1/shared/*
DirectAccess /bin/rm -rf /home/commuser1/shared/*

/usr/local/etc/commsh.d/commuser2.conf:

Allow commuser2 to run three scripts with partially specified parameters.
DirectAccess /opt/communities/bin/commuser2/script1 -input * -output *
DirectAccess /opt/communities/bin/commuser2/script2 -input * -output *
DirectAccess /opt/communities/bin/commuser2/script3 -input * -output *

The most important thing to understand when creating command restrictions is the difference between * and **, and what each of them will match.

A single asterisk (*) will match any character in a single argument. In general, this means it will not match a space unless the space is enclosed in quotation marks or escaped with a back-slash. Additionally, an asterisk in the command itself will not match a backslash (/). For example:

DirectAccess /opt/communities/*/script < *

Will match:

/opt/communities/one/script < input
/opt/communities/two/script < "input file"
/opt/communities/three/script < input\ file


But will not match:

/opt/communities/one/two/script < input
/opt/communities/one/script < input file

In contrast, a double asterisk (**) should only appear 
at the end of a command restriction specification, and indicates that 
any additional parameters will be 
accepted.

Activation / Shell Support

In order to activate commsh parsing for a given user, the user's shell 
must be changed to commsh. Exact details on how to change a user's shell 
vary from system to system. The community user's shell should be changed 
to:

/usr/local/bin/commsh




Or to the location where you installed commsh, if you specified a 
different installation location.


Typically, the shell must be added to /etc/shells (or a similar file) 
for the system to accept it as a valid shell.


GRAM support (optional)

GRAM support of commsh is not currently part of the standard GRAM 
installation. However, a simple patch will make it possible to use commsh 
to implement command-based restrictions on GRAM jobs.  This patch can also 
be downloaded from:

http://security.ncsa.uiuc.edu/research/commaccts/downloads/


To install the patch, run the following as user globus:

cp globus-job-manager-script.diff $GLOBUS_LOCATION/libexec
cd $GLOBUS_LOCATION/libexec
patch -p0 < globus-job-manager-script.diff


If the patch complains about 'fuzz', don't worry. The patch is designed 
to work with multiple versions of Globus. As long as both hunks succeed, 
the patch has been successfully applied.


Once the patch is applied, edit 
$GLOBUS_LOCATION/libexec/globus-job-manager-script.pl and 
uncomment the $FILTER_COMMAND line. Also change this line to 
point to your 
installation of commsh if you changed the installation location.

NOTE: Under some installations, such as TG CTSS, there are separate 
trees for each service. Under these installations, the patch must be 
applied to all directories serving GRAM, both WSGRAM (GRAM4) and 
pre-WSGRAM (GRAM2) services. Under TG CTSS, this should be the 
prews-gram directory as well as the globus-wsrf 
directory.




Administration


This section describes how to administer a community account without 
jeopardizing the security gains from command restriction by use of an 
administrative account.


The specific flaw that needs to be avoided is any model wherein an 
attacker with full access to the community account can place arbitrary 
executables in locations allowed by the command restriction. An example of 
such a flawed model is any model where the community applications live 
within the community account's home directory.


Our recommended solution, as described in the introduction, is to have an 
additional community administrator account for each community account. A 
simple naming scheme should be used. For our examples, we will assume that 
the community account is named commuser1 and the 
administrator account is named commuser1-admin.

Example /etc/passwd entries:
commuser1:x:5001:5001:Commuser User #1:/home/communities/commuser1:/usr/local/bin/commsh
commuser1-admin:x:5501:5501:Community Admin #1:/home/communities/commuser1-admin:/bin/bash

Community Applications


In most scenarios, community applications should be stored in a directory 
specific to that community. In our examples, the community account
commuser1 is restricted to running applications from 
the directory /opt/communities/bin/commuser1/. This directory 
is them owned by commuser1-admin.

Example of directory creation:
# mkdir -p /opt/communities/bin/commuser1
# chmod 0755 /opt/communities/bin/commuser1
# chown commuser1-admin:commuser1-admin /opt/communities/bin/commuser1
# ls -ld /opt/communities/bin/commuser1

drwxr-xr-x  2 commuser1-admin commuser1-admin 4096 Apr 1 12:00 /opt/communities/bin/commuser1

Applications can then be added to this directory either directly, or 
using symbolic links. Symbolic links are the preferred method when the 
application is already installed on the system for general use. The 
following example shows how the community administrator can use a 
symlink to include /usr/local/bin/compapp in the community 
account's applciations directory:
commuser1-admin@resource ~$ ln -s /usr/local/bin/compapp /opt/communities/bin/commuser1
commuser1-admin@resource ~$ ls -l /opt/communities/bin/commuser1

total 0
lrwxrwxrwx  1 commuser1-admin commuser1-admin 22 Apr 1 12:00 compapp -> /usr/local/bin/compapp



It is important that none of the applications be setuid 
or setgid, as in either case a poorly coded application can 
be used to secure administrative access and circumvent these security 
measures.