2.8. Authentification Module (AUTH)

2.8.1. Basics

This module can be seen as a support module for all others. It restricts CHANGE_OWNER on process targets (setuid) for a process: the request is only granted, if the process has either the auth_may_setuid flag set or the target user ID is in its capability set. The auth_may_setuid flag and the capability set are inherited on execute from the program file.

In other words: No setuid() variant system call will be allowed for any process running any program, unless the process (e.g. inherited from the program file) has either the flag auth_may_setuid set or an AUTH capability for the target uid.

A program file's capabilities can be set, if all modules grant a MODIFY_ATTRIBUTE request for A_auth_add_f_cap or A_auth_remove_f_cap. Process capabilities can only be added by other processes that have the auth_may_set_cap flag set, which is also inherited from their executed file.

This way an enforcement of daemon based authentification is possible, as well as a restriction of system daemons to a set of user IDs.

If enabled without a login program having auth_may_setuid or a capability set and without a capability setting daemon, you will not be able to login to your system! Use kernel parameter rsbac_auth_enable_login in emergencies or at the first boot to set auth_may_setuid for /bin/login.

With AUTH enabled, system daemons which setuid to a normal user account, like portmap, mysql or whatever, need an explicit capability to do so. They will only be able to use uids you granted.

2.8.2. AUTH attributes

All Processes have two auth flags: auth_may_setuid and auth_may_set_cap with the above meanings. These are inherited by all child processes.

All files have the same two flags, which replace those of the process on execute of the file.

Files and processes also have capability sets with the same inheritance rules. Adding to and removing from capability sets is restricted by different access control schemes for processes and files: process caps can be set by any process, which has the auth_may_set_flag set, whoever may be the owner of the process. File flags are set on behalf of users by any program.

2.8.3. Special Values

Up to version 1.0.9a, file capability sets can have the special value 65533 (UID -3), which is replaced by the owner of the process at the time the set is copied (execute time). Thus the process can come back to the original user ID after changing it. This value has been changed to 4294967292 (-3 again) in version 1.0.9b, which supports 32 Bit user ids.

2.8.4. Initial Configuration

Initially, nothing is allowed. Thus you have to enable the login of an AUTH security officer (uid 400 by default), who can do everything necessary. This can also be done with a maintenance kernel, setting appropiate values for all program files involved.

As a shortcut, you can use the kernel parameter rsbac_auth_enable_login, which set auth_may_setuid (full rights to change process owner) for /bin/login. This behaviour is hardcoded in the AUTH module data structures.

2.8.5. Administration

AUTH only restricts its administration, if this is enabled in the kernel configuration Administration is limited to users with system_role security_officer, and all involved attributes are protected.

Every module can further restrict the AUTH administration, if it depends on proper authentification. See the configuration menu help pages for more info.

Administration is mostly based on the file and process attributes and the capability sets mentioned above. See "instadm.htm" for more details.

2.8.6. When to use AUTH model

This model should always be used, because it controls which users can work on the system.All other models depend on proper user identification, which can be enforced with AUTH model.