dinsdag 20 november 2007

MAC user vs. DAC user

In a previous article i mentioned that one shortcoming of traditional Linux security is that the kernel can not make a distinction between a subject that was executed by the system or a process that was started by a user. I also mentioned that the Discretionary access control model only knows two users: root and user.

The Mandatory access control model tackles these issues with the user field in the security context tuple. We can now create as many SELinux user groups as we like. The kernel can now know who or what started a process. Be it a subject initialized by any kind of user, or a system daemon. This attribute is used by the security server to enforce policy defined by the administrator that is based on: who owns the subject or object.

On systems running the traditional targeted policy, system services are assigned to the system_u SELinux user group, and users are assigned to the user_u SELinux user group.

Policy that also makes use of the second role field in the SELinux security context tuple, like Strict, MLS or recent versions of policy Targeted use additional SELinux user groups to further group types of user domains to allow the administrator to apply policy that is targeted to the owner of a process.

The administrator can create additional SELinux user groups, he can assign roles, and levels to these user groups. Tailor made policy for each user group can be defined and enforced.

Process is often referred to as subject, (user or application) domain or source

maandag 19 november 2007

Why objects with incompatible types in tmp are not restored to a default type for that location

Traditionally the file contexts have explicitely excluded relabelling anything under /tmp. The reason for this is that if some highly classified data is in a file in /tmp it would not be appropriate to relabel it to a default label (of which incidentally there really isn't one for strict or MLS policies and even for targeted there is no single label that works in all situations). So a "fixfiles relabel" operation will offer to remove all files under /tmp

Thanks to rjc for letting me quote you in this article. You can view his blog at: http://etbe.coker.com.au/

Security contexts

SELinux enforces policy that is based on the relation of attributes of a subject to attributes of a object. These attributes are referred to as security contexts. Security contexts are a set of properties that are attached to objects and subjects. These property fields are: user, role, type, security level/security category. The combination of these fields is the security context.

Example of a simple security context:
user_u:role_r:type_t:s0

User Field:
This is the first of the four fields that make a security context. The user field has a SELinux user group. If a user is a member of the user_u user group than this field will be set to user_u. Processes that are started by the system will have a security context starting with the system_u field. Custom SELinux user groups can be created. For example if you want a user domain group to have access to specific roles than you can create a SELinux user group and define which roles this user domain should be able to transition to. On many SELinux systems, the default user_u group is not allowed to transition to any other role. User_u is reserved for unprivileged users.

Role Field:
This is the second of the four fields that make a security context. The SELinux role field has a SELinux role. Roles are only used by user domains and not by application domains. Therefore you will see a generic placeholder if you look at the role field in security contexts for objects. The role field for a user domain process may vary, as defined SELinux user groups are able to assume a new role. The role for a user domain that is member of the user_u SELinux user group may well be user_r. The role for a application domain is system_r. Security decisions based on this field are referred to as RBAC or role based access control.

Type Field.
This is the third of the four fields that make a security context. The SELinux type field has a SELinux type or domain. Types are assigned to objects, while domains are assigned to user domains and application domains. By default SELinux security is based on enforcing types. This is called TE or Type Enforcement. Access is determined on the relation of the source type field to the target type field. A Source is a domain and a Target is a type, because subjects operate on objects.

Security Level Field.
This is the last of the four fields that make a security context. The SELinux security level field has a security level. This field is, atleast at the moment, only used by multi level security policy used by government. But often support for MLS policy is enabled. If you do not use a specific MLS policy than you can disregard this field. With MLS policy, user domains get partitioned. This means that user domains operating on different security levels can not interact with each other. This is used to maximize integrity of data. On a default SELinux configuration with MLS enabled (but not necessarily a MLS policy loaded), this field may have a type of s0 which relates to the default security level 0 on which the system operates. This level is also referred to as SystemLow.

Multi level security also uses a model called multi category security. MCS will allow administrators to further confine user domains on that operate on security levels by using compartments.

For example: user_A operates on security level: 1 in compartment: office, while user_B also operates on security level :1 but in a different category: factory. Although both user domains operate on a same level, each user domain is also member of a different compartment. If a user is not a member of a compartment than access to objects in that category is denied, even when a user does operate on the same security level.

An example of a security context:
secret_u:user_r:user_t:s1:c0

This is a fictional user on a SELinux system with a MLS policy enforced. This user is part of the SELinux user group secret_u, the role of this user is a user role. This role has no privilege to change roles in a MLS invironment. The type field of this user domain is derived from the role field: user_t. This user operates on a non default security level 1 (called secret) and on that level this user domain has access to compartment c0. Where c0 could be office. This user operates on a secret security level in the office compartment of the security level.

SELinux security

SELinux security relies on a mandatory access control model. It takes into consideration policy that is defined by the administrator.

- More knowledge and time is required for administration

- Objects on a system are abstracted in two classes, subjects and objects. Subjects are user domains and application domains. Objects are files named_pipes dirs lnk_files fifo_files etc

- Offers fine grained control of security

- Ability to restrict access from subject to objects on a lower level

- Mandatory Access Control disregards Discretionary Access Control

Traditional Unix security

Traditional Unix security is based on a discretionary access control model. This discretionary access control model has properties that we must understand to be able to determine the advantages and disadvantages of this access control model and other access control models.

- It is to the discretion of the owner of the object to grant other users access to the object.

- Users are either root or user. The system can not see a difference between a process that was started by a user or executed by the system.

- Users could gain root privileges through objects that have setuid or setgid set. A process could escalate privileges.

- Access to objects are based on user identity.

- Access is liberal.

Documentation on domain specific booleans and security contexts

SELinux policy is based on a least privilege model. This means that by default, a user domain and a application domain have as little privileges possible over objects. Additional security contexts and tunable policies provide support for extra privileges that a user domain and application domain may require over objects.

Domain specific booleans and security contexts are documented and can be referenced on a system. For example the HTTPD policy has additional security contexts for objects that the HTTPD application domain may require extra privileges over. SELinux HTTPD policy also has additional tunable policies to provide additional functionality to the HTTPD application domain.

We can query these application domain specific tunable policies and security contexts with man httpd_selinux

How to determine if our system supports SELinux

SELinux is compiled into the kernel and is supported via Logical Security Modules. To determine if our kernel is compiled with SELinux support we must first determine our running kernels' kernel-release.

# uname -r
2.6.23.1-49.fc8


Once we determined our currently running kernels' kernel-release, we can query the configuration file that was used to compile this kernel.

# grep -i selinux /boot/config-2.6.23.1-49.fc8
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set


The config_security_selinux option is set to 'yes'. This means that SELinux support is compiled into this kernel. The config_security_selinux_disable option is also set to 'yes'. This means that SELinux is not enabled by default.

Or you could determine it the same way most people do: grep selinuxfs /proc/filesystems

To determine the current status of SELinux on our running system.

# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted

Thanks to Method for letting me quote you in this article. You can view his blog here: http://securityblog.org/brindle/