Absolute OpenBSD: Unix for the Practical Paranoid

Each OpenBSD user has a login class that defines limits on that user's access to system resources, how their environment behaves, and how users in that class authenticate. When you change the characteristics of a class, those limits affect all users in the class. All login classes are defined in /etc/login.conf.

You can change a user's class by running "chpass username" as root. Just put the class name in the "class" space provided, as shown in "Editing Users."

The Default Login Class

Whenever you create an account with adduser(8), that user is automatically assigned to the "default" class. The simplest way to manage login classes is to have the default class be the most commonly used class on your system. If your computer is an email server with a handful of administrators and several hundred mail users, set up the default class appropriately for the common case — the mail users. You can manually change the administrator's classes to a more appropriate one more easily than you can edit all those hundreds of users.

Class Definitions

Each class definition consists of a series of variable assignments. When a user logs in, login(1) uses these variables to establish the user's resource limits and environment setup. Each entry in the class definition begins and ends with a colon, although technically, each entry is all one line. The backslash character is a continuation marker, indicating that the computer should ignore the line break. Humans don't like 500 character lines of text, after all!

The standard /etc/login.conf starts with the "default" class. This gives the average user fairly broad access to the system. If you're running a modern system with gigabytes of RAM, you might find them too restrictive. If your OpenBSD box is a Pentium 166, however, these settings will basically give every user unlimited access to all system resources. If users consuming resources is a serious concern, you might well want to edit these settings. Here's a sample of the beginning of a login class.

default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin:\ :umask=022:\ :datasize-max=256M:\ ...

There are many more variables in a login class, but this should be enough to give you the idea. You can completely change a user's experience by assigning him to the class that configures his login environment as you desire.

Some login.conf variables don't have a value; they change account behavior just by their presence. For example, the "requirehome" variable just needs to be in the class definition to have effect.

:requirehome:\

Legal Values for /etc/login.conf Variables

You can give any of the following values to a login.conf variable assignment.

• Afull path to a text file.

• A comma-separated list of values.

• A number.

• A space-separated list of path names. If a ~ is the first character in a path name, the ~ is replaced by that particular user's home directory.

• A full path to a program.

• A size, either in bytes (default), kilobytes (k), or megabytes (m).

• A time, in seconds (default), minutes (m), hours (h), days (d), weeks (w), or years (y).

Some variables, of course, require particular sorts of values. A path to the home directory must be a full path, while the amount of memory the user may use cannot be a full path. In most cases, the legitimate answers are fairly obvious.

OpenBSD's default /etc/login.conf contains a few different classes of users. If you want an idea of what sort of restrictions to put on users for various situations, check that file. Here, we're just going to discuss some of the commonly changed items.

Resource Limits

Resource limits allow you to control how much of the system any one user can tie up at one time. If you have several hundred users logged in to one machine, and one of those users decides to compile 30MB of source code, that person can consume far more than his fair share of processor time and memory. By limiting the resources that one user can monopolize at one time, you can make the system more responsive for less needy users. You can also give different login classes different resource limits.

Resource limits are frequently tied to each process. If you allow each process to use up to 20MB of RAM, and you allow each user to start 20 processes, one user could theoretically consume up to 400MB of memory. Here are several popular resource-limiting login.conf variables.

Current and Maximum Resource Limits

The login.conf mechanism supports both advisory (or current) and maximum resource limits. Current limits (-cur) are generally advisory, and the user can override them at will. This works well on a cooperative system, where multiple users willingly share resources. Maximum limits (-max) are absolutes, and the user cannot exceed them.

To specify a current limit, add -cur to the limit name. To make a hard limit, add -max. For example, to limit the number of processes a user can have to 60, but give them a warning when they've used up half the maximum, you could do this:

:maxproc-cur=30:\ :maxproc-max=60:\

If you don't specify either -cur or -max, limits are hard limits and cannot be exceeded by the user.

Default Environment Setting

You can also specify default environment settings in /etc/login.conf. This can be better than setting them in a user's default .cshrc or .profile, as these settings affect all user accounts immediately upon each user's next login. Here are some common environment settings.

FTP Options

You can "chroot" FTP users to their home directory via the text file /etc/ftpchroot, but if you have a lot of FTP-only users you'll be better off using a login class to contain them. It is far more maintainable in the long run. Here are the FTP-affecting login.conf variables:

If you chroot FTP users it's a good idea to tell them so with a "welcome" message (as described under "Default Environment Settings").

Controlling Password and Login Options

You can control various password operations in /etc/login.conf. Unlike the environment setup, many of these can only be set in this file. OpenBSD also includes some very extensive methods to control how authentication works: see Authentication. Here are some common options for boring password authentication.

localcipher

This controls the password encryption method. This defaults to blowfish hashing, but you could set this to "old" for compatibility with the 56-bit DES hashes used in many older versions of UNIX.

login-backoff

This controls how quickly a user can try to log in. After this many login attempts, the login program starts to slow down how often it offers a login prompt.

passwordcheck

This gives the full path to an external program that will validate new passwords for quality. OpenBSD expects to pass the password to the program on standard input. The program is expected to return a 0 if the password is adequate or a 1 if the password is inadequate.

passwordtime

This is the lifetime of a password and can be used to enforce regular password changes.

minpasswordlen

This is the minimum length of a password.

Authentication Methods

You can also choose valid authentication methods in /etc/login.conf. OpenBSD uses "BSD Authentication," which works in a different manner than the popular Pluggable Authentication Modules used in quite a few open-source operating systems. You just identify the authentication method you want in /etc/login.conf, and OpenBSD will attempt to authenticate users by that method. It couldn't be easier than that!

Merely setting an authentication mechanism does not configure the authentication method — it merely tells the system to use that authentication method. For example, telling OpenBSD to authenticate a certain class of users via Kerberos V doesn't magically set up a Kerberos domain. Accounts who use a particular authentication method will be locked out if that authentication mechanism is unavailable.

Some authentication methods are simply not compatible with some protocols, so not all authentication methods work with all programs that provide logins. For example, while SSH works with cryptocards, it doesn't work with the password-changing "lchpass" authentication method. You need to check the man page for each authentication method for bugs and test unusual combinations.

Some of these authentication methods require additional login.conf variables, which are described in the manual page for that authentication method. For example, if you want to use Radius authentication, you need to tell login.conf where to find your Radius server. The manual page that describes the necessary configuration is given in the following table of common authentication methods. Here are the actual authentication methods supported by OpenBSD's BSD Authentication.

Using Authentication Methods

Authentication methods are set by login.conf's auth variable, with a commaseparated list.

:auth=skey,passwd:\

One interesting thing is the ability to specify different authentication methods based on the service the user is connecting to. You can specify a "service name" after the "auth" keyword, to state that a set of authentication methods only applies to that particular service. For example, to allow only password authentication for FTP, you could use this:

:auth-ftp=passwd:\

Here are a few of the commonly used authentication services:

For example, you could allow a user to log in with either their local password or S/Key, but if they want to use su(1) to become root, they must authenticate with S/Key. Here's a snippet from login.conf implementing that:

:auth=passwd,skey:\ :auth-su=skey:\