This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at https://wiki.gentoo.org
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.
Introduction
The relation between SELinux users, Linux accounts, SELinux roles and the supported domains is shown in the following drawing.
SELinux users
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.
For instance:
- The
user_u
SELinux user linked with theuser_r
role. This role is allowed to run non-administrative applications (the set of supported SELinux domains). - The
staff_u
SELinux user on the other hand is linked with both thestaff_r
role andsysadm_r
role. That means that users mapped to thestaff_u
SELinux 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 newrole_t
domain.
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 staff_r role) and administrative commands (through the sysadm_r role).
|
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 git_shell_u
, guest_u
and 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 staff_u
or sysadm_u
whereas unprivileged users are mapped to user_u
.
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
With semanage login
, the current mappings can be shown.
root #
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.
root #
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 *
The __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 users
group.
Creating a new mapping
To create a new user mapping, use semanage login
.
For instance, to map the Linux user darcia to the staff_u
SELinux user:
root #
semanage login -a -s staff_u darcia
On MLS-enabled systems, a security clearance can be passed on as well:
root #
semanage login -a -s staff_u -r s0-s0:c0.c100 darcia
Modifying an existing mapping
Modification of existing mappings is also done with semanage login
.
For instance, to modify the mapping for user darcia to now be mapped with the sysadm_u
user:
root #
semanage login -m -s sysadm_u darcia
Or to modify the security clearance on an MLS system:
root #
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 --force
(-F
) argument:
root #
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 __default__
mapping:
root #
semanage login -d darcia
If this results in a change of SELinux user, do not forget to relabel the files of the user:
root #
restorecon -RF /home/darcia
Managing SELinux users
Management of SELinux users is done using semanage user
.
Listing SELinux users
List the current set of SELinux users with semanage user -l
:
root #
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:
root #
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 semanage user
.
For instance, to create a SELinux user swift_u
with access to the staff_r
and dbadm_r
roles:
root #
semanage user -a -R "staff_r dbadm_r" swift_u
The use of the
_u
suffix is not mandatory, but a best practice.On MLS-enabled systems, the default clearance for the SELinux user can also be provided:
root #
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 semanage user
.
For instance, to update the role set of the swift_u
SELinux user to become staff_r
dbadm_r
and webadm_r
:
root #
semanage user -m -R "staff_r dbadm_r webadm_r" swift_u
The MLS clearance can be modified as well.
root #
semanage user -m -r s0-s0:c0.c50 swift_u
Removing custom SELinux users
Custom SELinux users can be removed using semanage user
.
For instance, to remove the swift_u
user:
root #
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.
Summary
By supporting SELinux users and login mappings, additional constraints on users' permissions can be set.