SELinux/Users and logins
In an SELinux context, the first part is called the SELinux user. The purpose of a SELinux user is to have an immutable part in a context (i.e. one that the user cannot change himself) both to assist in auditing (who did what) as well as access controls (users cannot work around SELinux user based restrictions). But a SELinux user is not the same as a Linux account. For that, user mappings are put in place that map a Linux user to a SELinux user.
- 1 Introduction
- 2 Managing login mappings
- 3 Managing SELinux users
- 4 Summary
The relation between SELinux users, Linux accounts, SELinux roles and the supported domains is shown in the following drawing.
A SELinux user is an identifier that administrators can use to limit which SELinux roles can be used. A Linux account is mapped to one (and only one) SELinux user, whereas a SELinux user can be linked to multiple roles. As shown in the drawing above, SELinux users define which roles can be used. As roles define the privileges of a user, this is effectively used to limit the ability of users to run or execute particular applications.
user_uSELinux user linked with the
user_rrole. This role is allowed to run non-administrative applications (the set of supported SELinux domains).
staff_uSELinux user on the other hand is linked with both the
sysadm_rrole. That means that users mapped to the
staff_uSELinux user can switch between those two roles.
One of the supported domains,
newrole_t, is meant for the
newrole application which allows users to switch roles. As the
user_u SELinux user does not need to switch roles, the
user_r role is not allowed to use the
The following table gives an non-exhaustive list of SELinux users which can be found on most SELinux systems.
|SELinux user||Description||Used for|
|unconfined_u||SELinux user meant for unrestricted users. Unconfined users have hardly any restrictions in a SELinux context and are meant for systems where only Internet-facing services should run confined (i.e. the targeted SELinux policy store).||All users on a targeted system|
|root||The SELinux user meant for the root account||The Linux root account|
|sysadm_u||SELinux user with direct system administrative role assigned||Linux accounts that only perform administrative tasks|
|staff_u||SELinux user for operators that need to run both non-administrative commands (through the
||Linux accounts used for both end user usage as well as administrative tasks|
|user_u||SELinux user for non-privileged accounts||Unprivileged Linux accounts|
|system_u||Special SELinux user meant for system services||Not used directly|
The list is definitely not complete though. Some distributions offer additional SELinux users by default, such as
xguest_u. As the purpose of SELinux users is to restrict what a user can do, the purpose of these specific SELinux users can usually be retrieved from their name - and if not, by querying the roles that they are linked with.
Next to the role mapping, SELinux users can also define the highest clearance of all users mapped to the SELinux user. Linux users cannot gain a higher security clearance than is set for the SELinux user (but they can be assigned a lower clearance).
SELinux login mappings
SELinux login mappings allow for the Linux administrator to map a Linux account to a SELinux user. When a Linux user logs in, a user table is consulted which contains the mappings of users to SELinux users. Based on that information, the initial context is set up for the user (which also contains the SELinux role and user domain). Unlike SELinux users, which can be linked with multiple SELinux roles, user mappings map a user to one (and only one) SELinux user. Multiple Linux users can be mapped to the same SELinux user though.
On a targeted system, all users are mapped to the
unconfined_u SELinux user. Otherwise, administrative users are mapped to either
sysadm_u whereas unprivileged users are mapped to
On MLS-enabled systems, login mappings can also provide a lower security clearance for individual users, even though the SELinux user has a higher clearance set. Once a clearance is set for a particular user, this user cannot gain a higher clearance - so the clearance of the SELinux user is not a reachable set, but should be seen as a "default" value for login mappings if no clearance is given to the mapping itself.
Managing login mappings
Most administrators will not need to manage SELinux users, but the Linux mappings will be an important table to maintain.
Listing current mappings
semanage login, the current mappings can be shown.
semanage login -l
Login Name SELinux User __default__ user_u root root swift staff_u system_u system_u
If the system supports MLS, then the sensitivity / security clearance of the users is also shown.
semanage login -l
Login Name SELinux User MLS/MCS Range Service __default__ user_u s0 * oper staff_u s0-s0:c0.c1023 * root root s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 * test user_u s0 * user user_u s0 *
__default__ mapping is a special, fall-back mapping. When no particular mapping matches, then the
__default__ mapping is used.
Also, if a login name starts with the
% sign, then it will match group membership. For instance, a mapping
%users mapping will match all Linux users whose primary group is the
Creating a new mapping
To create a new user mapping, use
For instance, to map the Linux user darcia to the
staff_u SELinux user:
semanage login -a -s staff_u darcia
On MLS-enabled systems, a security clearance can be passed on as well:
semanage login -a -s staff_u -r s0-s0:c0.c100 darcia
Modifying an existing mapping
Modification of existing mappings is also done with
For instance, to modify the mapping for user darcia to now be mapped with the
semanage login -m -s sysadm_u darcia
Or to modify the security clearance on an MLS system:
semanage login -m -r s0-s0:c0.c20 darcia
If the SELinux user for a user has been modified, it is important to relabel the files of that user using the
restorecon -RF /home/darcia
Also have the user log out before modifying and resetting the contexts.
Deleting a mapping
It is possible to delete a mapping so that the user falls back to the
semanage login -d darcia
If this results in a change of SELinux user, do not forget to relabel the files of the user:
restorecon -RF /home/darcia
Managing SELinux users
Management of SELinux users is done using
Listing SELinux users
List the current set of SELinux users with
semanage user -l:
semanage user -l
SELinux User SELinux Roles root staff_r sysadm_r staff_u staff_r sysadm_r sysadm_u sysadm_r system_u system_r unconfined_u unconfined_r user_u user_r
On MLS-enabled systems, the sensitivity and the security clearance is listed as well:
semanage user -l
Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_u unconfined s0 s0-s0:c0.c1023 unconfined_r user_u user s0 s0 user_r
Creating custom SELinux users
It is possible to create additional SELinux users with
For instance, to create a SELinux user
swift_u with access to the
semanage user -a -R "staff_r dbadm_r" swift_u
The use of the
_usuffix is not mandatory, but a best practice.
On MLS-enabled systems, the default clearance for the SELinux user can also be provided:
semanage user -a -R "staff_r dbadm_r" -r s0-s0:c0.c100,c201 swift_u
Updating custom SELinux users
SELinux user settings can be modified using
For instance, to update the role set of the
swift_u SELinux user to become
semanage user -m -R "staff_r dbadm_r webadm_r" swift_u
The MLS clearance can be modified as well.
semanage user -m -r s0-s0:c0.c50 swift_u
Removing custom SELinux users
Custom SELinux users can be removed using
For instance, to remove the
semanage user -d swift_u
Make sure that all mappings towards this SELinux user are updated before removing the SELinux user itself.
Also relabel all resources that might currently be "owned" by this SELinux user so that their SELinux user is not invalidated.
By supporting SELinux users and login mappings, additional constraints on users' permissions can be set.