SELinux with omarine policy: SELinux User Capabilities

Posted by: Tuyen Pham Thanh 4 years, 1 month ago

(0 comments)

Unlike Linux users where each user has a specific name like tho, emin, SELinux user is a group of users that have the same capabilities in terms of security context. For example, the standard SELinux user is user_u, the administration staff is staff_u. By convention, SELinux user names usually end with _u. The special case, the Linux root user corresponds to root in SELinux, still. The SELinux user name is the first part of the security context.

All processes and objects (such as files) combine with a security context. It is represented by strings of four parts: the SELinux user, the role, the type identifier, and the security range. In that range is optional, only for MCS / MLS policy. Because the omarine policy supports MCS, all four components of the security context are present in Omarine. The form of a security context is as follows:

user:role:type:range

Where:

• user: SELinux user identity, which can be associated with one or more roles the SELinux user is allowed to use.

• role: SELinux role, can be associated with one or more types the SELinux user is allowed to access.

• type:
  
  
  • When a type is associated with a process, it defines what processes (or domains) the SELinux user (the process subject) is allowed to access.
  
  
  • When a type is associated with an object, it defines object access permissions for the SELinux user (the process subject).

• range: This field represents the security level, which can consist of:
  
  
  • A single security level that contains a sensitivity level with zero or more categories, for example s0, s0:c0
  
  
  • A range consists of two security levels (low and high) separated by a hyphen, for example s0-s0:c0.c1023

You can run the semanage user -l command to view the SELinux user list in the omarine policy:

You can add SELinux users such as guest_u, however.

SELinux User Capabilities

The default SELinux user capabilities in the omarine policy is as follows

Note:

• xdm in omarine is gdm. root can use X Window System, but can not use xdm. Although we can make adjustments to allow root to login through gdm, this is not recommended because its permissions are too strong in a desktop environment that has many sensitive applications. In addition, convenient utilization may damage the system.

• Media access capability is the ability to access additional mounted disks from the outside into the system. The condition for staff_u to use su / sudo and to access media is that its Linux user must be in the wheel group.

• When you install Omarine, you have the default user mapped to staff_u with enough capability. If you create more users in the traditional Linux way, the user created by default will be mapped to user_u.

• sysadm_u is present in the SELinux user list but not necessary and not be updated policy to use. Use root instead for system administration.

Unlike traditional Linux, in SELinux sudo does not have the capability as root, it works in the <role_prefix>_sudo_t domain. For example, if you run sudo as staff_r role, the current domain will be transitioned to the staff_sudo_t domain. The capability of this domain depends on the policy. For example, staff_sudo_t can create files in the /etc directory, but can not create files in the /etc/mail directory, as the policy does not allow it. Confining the applications is generally a great way for security purposes.

If you need to perform an operation that you know is necessary but can not be done by sudo, switch to use su. su defaults to becoming root with sysadm_t domain and you can handle most things, except in a few cases, for example sysadm_t transitions to an intermediary domain but that domain is not allowed to do. If still confined you can switch to permissive mode by running the following command as the seuser root (can use su):

setenforce 0

To return to enforcing mode:

setenforce 1

Finally, you can add some rules to the policy if you are very motivated.

• ← SELinux with omarine policy: An in-depth look at the security policy – secure program with its own domain: Part 8
• SELinux with omarine policy: An in-depth look at the security policy – secure program with its own domain: Part 9 →