Unlike all traditional user and group schemes in Linux, the User (and group) Management in RSBAC is completely kernel based. It can be used as a more powerful and much more secure replacement.

Note: This functionality is of course, optional, but recommended. For configuration see User Management Configuration.

The administration of users is enforced with granularity and more flexibility. One of the key features is that you can allow a process to change it's user id only to the last one that has been authenticated.

For example, /bin/login tries to authenticate user id 1000 and succeed, thus RSBAC will allow changing to this user id and start a session. Without this functionality, if there was a bug in /bin/login, an attacker could make this program ask for changing to user id 1000 without authenticating successfully, and would not be denied (even with other RSBAC functions enabled, as long as /bin/login is authorized for user id 1000).

RSBAC also support virtual user sets. User lookups, authentication, etc. can be completely virtualized per process, program or jail. This means, that you can have a different user “bob” accessing your FTP server than the user “bob” having a shell access, even if the FTP server does not include its own code to support virtual users, and with all the previous UM advantages. And you can add one-time passwords for protection against eavesdropping of passwords.

There are several other advantages that you will discover by reading this documentation :)

The traditional Linux user management, specially the common passwd/shadow scheme with PAM, has several security problems:

1. PAM libraries running in process context: The PAM libraries are mapped into every process, which has to authenticate users or change user accounts. This means that every single such process must have read or even write access to sensitive authentication data, and an exploit in only one of them reveals all this sensitive information to an attacker. Not using PAM does not help here, because the process still needs the same access.
2. No granularity: If a process has access to sensitive account or even authentication data of one user, it has access to the same for _all_ users in the system, even the administration accounts.
3. Changing passwords: Because of 2., a program which allows password changes by the user (usually passwd), also has access to all passwords. An admin account which is allowed to set new passwords for normal users, who tend to forget their passwords, can do the same for any user - including other admins. This means this admin can get access to all other admin accounts, even if direct access is not allowed through RSBAC access control.
4. Password attacks: As encrypted passwords are readable for too many processes, they can be guessed via dictionary attacks. Worse, the old crypt is easy to crack, and even the MD5 replacement is rumored to be attackable with databases of precomputed MD5 strings.
5. Process choosing the uid to change to: Any process with sufficient rights (CAP_SETUID and CAP_SETGID in Linux) can change to any uid it wants. Even the RSBAC v1.2.3 AUTH module functionality does not help against buggy login programs - they are supposed to setuid to a big range of uids, and the kernel cannot tell whether these have been authenticated or not.
6. Current implementation of passwd/shadow: The current PAM implementation of the passwd/shadow scheme does not modify the files - it creates new ones and replaces the old ones with the new ones. There is nothing bad in avoiding inconsistencies in the absence of good locking - but it means the objects on disk constantly get new ids. As two different files have to be protected with different access rights (shadow must be inaccessible to normal users, passwd must be readable), it is almost impossible to protect them without race conditions.

Now, what is the difference in the new RSBAC User Management?

1. No process has direct access to user account or authentication data. All password checks etc. are done inside the kernel. The new RSBAC PAM and NSS modules only call the appropiate system calls, so an attack against a process mapping them does not help at all.
2. Access rights to user account and authentication data are separate for every single account. There are different rights for access to them:
   • SEARCH: Get the mapping between uid and name
   • GET_STATUS_DATA: Read group, homedir, fullname or shell. The user usually needs this, other users usually do not.
   • READ: Get the user info usually placed in shadow: password validity, expiring etc. Usually only needed for account management.
   • WRITE: Change group, homedir, fullname, shell or the info usually in shadow.
   • GET_PERMISSIONS_DATA: Read the SHA1 encrypted password. Usually not needed, except for backup.
   • MODIFY_PERMISSIONS_DATA: Change the password. This is what an admin needs to reset a user password - but only for a limited set of users, and this right does not allow to read the previous password.
   • CREATE: Add a new user. How this is checked depends on the security model. E.g. RC roles have a default_user_create_type, so you need the right to this type.
   • DELETE: Delete a user account.
   • RENAME: Rename a user account.

Group protection is very similar, only the number of settings is smaller.

1. See 2.: You need MODIFY_PERMISSIONS_DATA for the particular user, not for all users.
2. No one except the backup program can read the encrypted password, so offline password attacks are almost impossible. All an attacker can do is brute force through login, what will take a looooong time because of delays after each failure.
3. In combination with AUTH module, a login program can only setuid to the last authenticated uid. If it did not authenticate a uid against the kernel, setuid simply fails. To enable this, set AUTH auth_may_setuid to the new value last_auth_only or last_auth_and_gid. The latter allows to reach any group, because groups cannot be authenticated at login. Furthermore, the UM exclusive mode only allows to setuid or setgid to uids and gids known to UM, so an attacker cannot use an uncontrolled uid, even if AUTH allows to setuid to any uid.
4. User and group data are always protected, so there is no such race condition.

Starting from version 1.4, RSBAC contains Virtual User Management (VUM), which is an extension to the existing User Management (UM).

Every user id now consists of a 32 Bit virtual set (vset) number and the old fashioned 32 Bit uid. The normal set of users is vset 0. It also exists, if VUM has been turned off in kernel configuration. All other vset numbers can be used as desired, there is no list of known sets.

User id u in vset s is consistently written as s/u. User name n in vset s is written as s/n. To login into set s, use s/username at the login prompt, e.g. 100/joe. All RSBAC tools accept the new notation of users. Every s/u has its own password, its own home directory, its own attributes, etc. RSBAC kernel logging uses the same notation, except that it does not write 0/n, but simply n for backwards compatibility and ease of use.

Every process has a current vset, so its s/u pair is taken from current vset and real uid. Access control, role changes etc. simply take the vset into account.

Vsets can be assigned to programs, e.g. an FTP daemon, to make a service run with a different set of users. Ever wanted to make sure that FTP attackers cannot crack passwords of SSH users? Well, separate the sets of users, done. On the fly, you can also get different access rights depending on the service you used for login.

Alternatively, a vset can also be given as parameter to the rsbac_jail command to start a program in a certain jail. As a general rule, every process with real uid u can change its vset from 0 (default) to another vset s, if it has the right to CHANGE_OWNER to s/u. As usual, this can be limited with AUTH (cap s/u), RC (CHANGE_OWNER right to type of s/u) or ACl (ACL at s/u).

By default, there is no way back to vset 0, and a process with another current vset than 0 cannot see any other vset's users. This restriction can be removed by a kernel config switch, in that case you will have to use access control to protect your vsets from being seen.

To make setups a bit easier, you can define default attribute values for a complete virtual user set s through the special user RSBAC_ALL_USERS, written as s/ALL. This value is used for all users in the set, which have no explicit value for that attribute. As an example, give all users in vset 10000 the RC type 10000 (through 10000/ALL) and only allow AUTHENTICATE to that user type for the FTP daemon running in that vset.

Also, AUTH now supports capabilities all/u1:all/u2 for u1 to u2 in all virtual sets. E.g. set AUTH cap all/0 on rsbac_jail so that it can CHANGE_OWNER to all virtual sets you specify in its command line.

To get your current set used for some user n, use auto/n or simply n. The PAM and NSS libraries always use auto vset, unless you write s/ before the user name or id.

For configuration see Virtual User Management Configuration

With the 1.4 release, RSBAC also supports One-Time-Passwords (OTP). After enabling in the RSBAC kernel config, you can add a limited amount of extra passwords to each user account. All these extra passwords can only be used once.

A typical usage szenario is accessing your mail from an Internet cafe or the quite common “can I have your password for some quick access”. In both cases, revealing your real password to the public is no longer necessary.

For configuration see Virtual User Management Configuration

Table of Contents: RSBAC Handbook
Previous: Architecture and Implementation
Next: Security Modules