COMMSH.CONF

NAME
DESCRIPTION
DIRECTIVES
COMMAND PARAMETERS
SEE ALSO
AUTHOR
COPYRIGHT

NAME

commsh.conf − Community Shell configration file

DESCRIPTION

commsh.conf contains a list of directives that determine the behavior of commsh, the Community Shell.

A directive is of the form:

DirectiveName [Value [Value ...]]

Each Value can be either a boolean keyword (true, on, yes versus false, off, no), an integer (octal and hexadecimal forms are allowed, e.g. 0777 or 0x4A), or a string. Multi-word strings must be enclosed in quotation marks (e.g "one two three"), and both quotation marks and newlines can be escaped using \.

If a directive is given without any values, a true boolean value is assumed.

Blank lines and lines starting with a # (comments) are ignored.

DIRECTIVES

An * denotes directives that are not currently implemented.

General

ReadConfig FILE

Read the configuration file found at FILE as if it were appended to the end of the main configuration file. Note that tildes in FILE are expanded.

ReadUserConfig UID/USERNAME FILE

Behaves as ReadConfig if UID/USERNAME matches the current user.

AllowUser UID/USERNAME

Allows the given user to run commsh. By default, nobody is allowed access. The special value of may be provided to allow any user that has not been explicitly denied (see DenyUser below).

DenyUser UID/USERNAME

Explicitly deny the given user from running commsh. This option has no effect unless has been specified.

AssignUID UID

Assign a static UID to be assigned. (By default, the UID of the user is preserved.) This option is ignored if dynamic account generation is enabled (see below).

Change Root

ChrootPath [PATH/BOOL]

If BOOL is true or a PATH is provided, chroot functionality is enabled. The default path is the user’s home directory, and tilde expansions in a provided path are performed. Before chroot is called, the path will be checked for security risks (see CheckChroot below).

CheckChroot [CHECK [CHECK ...]]

Before chrooting to a jailed environment, perform the specified checks.

Possible checks include:

suidroot

Check for files setuid root

suid

Check for files with the setuid bit set

sgid

Check for files with the setgid bit set

block

Check for block devices

char

Check for character devices

socket

Check for UNIX sockets

fifo

Check for FIFO pipes

mount

Check for mount points.

all

Perform all checks (default)

CheckAllowDevice DEVICE

Allow the given DEVICE to exist within the jail. DEVICE should refer to a file in the real filesystem (not the jailed environment). The actual path to this file is not relevant, as the only checked characteristics are the file’s mode, rdev, uid and gid. This only matters for block and character devices, sockets and FIFO pipes (the latter two of which don’t have an rdev to check), and then only if the corresponding CheckChroot parameter has been set.

Dynamic Account Generation

*AssignDynamicUID MIN MAX

Enables generation of dynamic accounts and specifies the range of UIDs (incluive) to use during generation. If MIN or MAX begins with a + or - sign, then its value will be interpreted relative to the user’s real UID. For example, if the user’s UID is 1000 and the range is [1,100], then UIDs 1001 through 1100 will be used. If no UIDs within the range are available, the login will fail and an error will be recorded.

*DynamicCachePath PATH

Specify the location to store cached dynamic account information. This inofmration is used to reap old dynamic accounts as well as to store authentication tokens for reauthentication to an existing account. ~ expansion will take place based on the user’s pre-chroot home directory. This option must be specified for dynamic account generation to work.

*DynamicHome PATH

Specifies the path to use as the home directory for a dynamically generated account. ~ expansion will take place based on the user’s post-chroot home directory, and the following other escape sequences will function:

%u

Post-chroot username

%d

Dynamically assigned UID

%n

Original UID

%~

Post-chroot home directory (same as ~)

If the specified directory already exists, then it will still be used but it won’t be instantiated from a template (see DynamicHomeTemplate below).

*DynamicHomeTemplate PATH

Specifies the path to use as a template for dynamically generate home directories. All files and directories in the specified template will be copied into the newly created directory. If this option is not specified, dynamically generated home directories will be empty.

*DynamicShell SHELL

Specifies the shell to use after assigning a dynamic UID. If not specified, the shell for the original UID is used (as determined from within the chroot jail) as long as that shell isn’t named commsh. If no such shell can be determined, /bin/sh is used by default.

*DynamicExpiration TIMESPAN

Specifies the length of time that a dynamic account is allowed to exist before being removed from the system (aka reaped). Accounts are not guaranteed to be removed after this length of time has passed, but they are guaranteed not to be removed earlier than this. This time is measured from the most recent successful login to the account, and not from logout.

TIMESPAN must be specified as an integral number of minutes, and defaults to 10080 (one week.)

*DynamicAutoReap True/False

If true, expired dynamic accounts will be reaped every time that commsh is run. Otherwise, commsh --reap must be run in order to delete expired accounts and free up dynamic UIDs.

*DynamicAllowReuse True/False

If true, authentication tokens will be generated for dynamic accounts allowing the accounts to be reused. These tokens will be sent as part of the initial login message, and reauthentication is possible by specifying them in the command string. The exact format is: where COMMAND can be left blank.

Access Methods

*LaunchShell True/False

If true, exec the user’s shell after authentication, passing to it any command parameters. If false, commands will be executed directly as long as they match a DirectAccess directive (see below).

*AllowSftp True/False

If true, sftp access will be allowed to the account. If a chroot jail is in use, the sftp subsystem must exist within the jailed environment.

*DirectAccess CMD

Allow direct access to a given command. This has no effect if LaunhcShell is enabled. The format of the commands is described in COMMAND PARAMETERS (see below).

COMMAND PARAMETERS

The command parameters used by the DirectAccess directive conform to the following specifications:

The command issued must match the specified command exactly. If command parameters are expected, they must be included explicitly in the format of the command. Wildcard matching is included, but wildcards will not match spaces.

Optional parameters can be specified by enclosing them in brackets ([]). If a wildcarded parameter is preceded by a tilde (~), then only files in the user’s home directory can be specified.

A final parameter of ** specifies that the user can add any number of additional parameters to the end of the command.

Examples:

DirectAccess /bin/rbash

Allow the user to launch a restricted bash environment without parameters

DirectAccess /usr/bin/whoami [--*]

Allow the user to execute whoami with an optional -- option

DirectAccess /bin/cat ~*

Allow the user to execute cat on any file in the user’s home directory

DirectAccess /usr/bin/jobmanager **

Allow the user to execute jobmanager with any parameters

SEE ALSO

commsh(1)

Community Shell (commsh) is a component of the NCSA Restricted Community Accounts project.

Project website: http://security.ncsa.uiuc.edu/research/commaccts

AUTHOR

Kevin J. Price <kjprice@ncsa.uiuc.edu>

National Center for Supercomputy Applications (NCSA), http://www.ncsa.uiuc.edu/

COPYRIGHT

Copyright (c) 2005-2006, The Board of Trustees of the University of Illinois. All rights reserved.