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 rumoured 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.

You can remove the complete shadow suite with pam_unix, /etc/passwd*, /etc/shadow*, /etc/group*, /etc/gshadow*.

Still, I recommend keeping the PAM helper stuff, e.g. pam_cracklib.so. Just replace pam_unix.so in your PAM config files with pam_rsbac.so.

The rsbac_useradd and rsbac_groupadd commands can import existing accounts and groups, except for the passwords. These must be set manually for all accounts, RSBAC does not include password crackers. ;) Sure this has to happen before you remove pam_unix and the files and before you change PAM and NSS config. It is sometimes necessary to rerun the import to get cross dependencies between groups and users right. You can check your groups and users with rsbac_groupshow and rsbac_usershow.

The old {user|group}{add|mod|del}, passwd programs with PAM and NSS support should continue working as before, but you can also replace them with rsbac_. A symlink in /usr/local/bin works fine, if this dir is before /usr/sbin in the PATH setting. Additionally, if you have no PAM, you can replace the old login with rsbac_login, which only understands RSBAC UM.

After testing on real server systems, I can gladly say that almost all Linux programs use the standard library calls and are thus compatible with the new user/group scheme, if the PAM and NSS helper libraries have been installed and configured.

User management (UM) must be enabled in RSBAC kernel configuration. To get passwords encrypted with SHA1, this algorithm must first be enabled in the kernel Crypto menu. Only with SHA1 enabled, the User Management menu will show the option for encryption! After configuration, compile and install the kernel as usual.

The RSBAC admin tools contain the necessary user and group management tools with the usual Linux names ({user|group}{add|mod|del}, passwd, gpasswdm, login), but prefixed with rsbac_. Additionally, there are tools to retrieve and backup info, namely rsbac_usershow and rsbac_groupshow. The rsbac_login command does not support PAM, it only understands RSBAC UM. These tools can be used as direct replacements, e.g. make a symlink in /usr/local/bin, if this dir is first in PATH.

Both rsbac_useradd and rsbac_groupadd have options to convert existing users and groups. As standard Linux passwords are encrypted with another algorithm and salt size, they cannot be converted. Thus, passwords for converted users and groups must be reset, e.g. with the rsbac_usermod command. To get dependencies between users and groups right, run “rsbac_useradd -v -O” before “rsbac_groupadd -v -O” and repeat the import, if necessary. Always check the results with rsbac_usershow and rsbac_groupshow.

To enable normal Linux user programs to see and use RSBAC UM, you need to compile and install the NSS and PAM modules from the admin tools contrib dir. Change /etc/nsswitch.conf (replace compat in passwd, group, shadow by rsbac) and /etc/pam.d/* (replace pam_unix with pam_rsbac). Then it simply works - if you granted the necessary access rights and imported the existing users and groups, that is. It is generally a good idea to run in softmode first. :)

For soft migration and first tries, you can run passwd/shadow and RSBAC UM in parallel for a while, before you turn the first off: In nsswitch.conf change “compat” to “compat rsbac”, in /etc/pam.d/* add “ sufficient pam_rsbac.so” before the pam_unix.so line.

New in 1.2.5: If you want to use pam_rsbac.so together with pam_cracklib.so, passwd will first ask for the new password before pam_rsbac asks.so for the old password. This behaviour breaks some programs, e.g. kdepasswd, and does not match most users' expectations. Thus, pam_rsbac_oldpw.so simply asks for the old password, stores it in PAM and returns success. An /etc/pam.d password file could look like this:

password required pam_rsbac_oldpw.so
password required pam_cracklib.so retry=3 minlen=8 difok=3
password required pam_rsbac.so

After complete migration, you can enable UM exclusive mode to disallow all users and groups unknown to UM. auth_may_setuid settings should be changed from full to last_auth_and_gid to deny unauthenticated setuids, and AUTH caps should be properly reduced.

Table of Contents: RSBAC Handbook
Back: Security Models