From Fedora Project Wiki

< Docs‎ | Drafts‎ | SELinux User Guide
Revision as of 01:04, 14 August 2008 by Mdious (talk | contribs)

Content Specification

SELinux Introduction

On Linux operating systems, everything is represented as a file. For example, a hard disk can be represented as the /dev/hda file, and processes, such as Mozilla Firefox, are represented as files in the proc file system (/proc). These files are called objects. Linux operating systems use a Discretionary Access Control (DAC) system, that defines access to these objects. Users have access to change permissions for files and directories that they own. They could, for example, make their home directory world-readable, potentially allowing access to privileged information from other users, or giving processes, such as a Web server, access to serve these files.

Security-Enhanced Linux (SELinux) provides a Mandatory Access Control (MAC) system -- that is built into the Linux kernel -- for Linux operating systems. MAC restricts the control users have over the files and directories that they create. SELinux allows files, and therefore everything on a Linux system, to be labeled. MAC rules allow all available information to be used to make access decisions, instead of only a user and a group. MAC rules are checked after DAC rules.

What SELinux Can Do

With SELinux, processes (subjects), such as the Apache HTTP server, run in a restricted domain. Files (objects) are labeled with a type. This type is used by Type Enforcement, which is used by MAC. SELinux policy defines the interaction subjects have with objects. This means that if the Apache HTTP server is compromised, the attacker only has access to files labeled with the correct type. Each file is labeled with an SELinux user identify, a role, and a type: selinux-user-identity:role:type.

SELinux offers:

  • Type Enforcement (TE): fine-grained access control. MAC allow/disallow actions are checked after DAC permissions. All Files are labeled with a type. Access is only granted if it is specifically defined - the default action is to deny access. This prevents subjects (processes), such as Samba and FTP, from accessing files they should not have access to, for example, files in user home directories.
  • Fine-grained access control: Type Enforcement allows for fine-grained access control. For example, the Apache HTTP server can only access files that are labeled with the httpd_sys_content_t type, and not files that are labeled with the user_home_t type, which is the type used for files in user home directories.
  • Preventation against privilege escalation: subjects run in restricted domains. For a process, the type attribute defines which domain the process runs in. By default, a subject running in one domain can not access another domain. If a Web server is running in a protected domain, and that Web server is compromised, an attacker can only access files that the Web server has access to. SELinux also provides confined user types. Depending on the type selected, this can prevent: the use of X windows, executing files in home directories, network access, executing binaries that have the set user ID bit set, and so on.
  • Role Based Access Control (RBAC): every object (files, sockets, and so on) and subject (processes) is labeled with an SELinux user identity, a role, and a type. For a subject, the type defines the restricted domain the process runs in. The role attribute defines which SELinux user identities can access which domains.
  • Logging:

Policy Overview

Examples

Processes being compromised, but not allowing an attacker to take over the whole system

Performance

Part of the SELinux LSM module is the security server. The security server contains policy rules, which define what access is allowed. Hooks in the Linux kernel communicate with the security server for access decisions, such as allowing or disallowing a process access to a file. An Access Vector Cache (AVC) caches decisions made by this server. This decreases how often rules in the security server need to be checked for, which increases performance.

When running SELinux in permissive mode, access rules are still checked; however, when a denial occurs, the denial is logged, and access is allowed. There is no performance decrease when SELinux is disabled, as the SELinux module is not registered with the kernel.

SELinux Contexts and Attributes

As previously mentioned, on Linux operating systems, everything is represented as a file. For example, a hard disk can be represented as the /dev/hda file, and processes, such as Mozilla Firefox, are represented as files in the proc file system (/proc). These files are called objects. Linux operating systems use a Discretionary Access Control (DAC) system, that defines access to these objects. Users have access to change permissions for files and directories that they own. They could, for example, make their home directory world-readable, potentially allowing access to privileged information from other users, or giving processes, such as a Web server, access to serve these files.

Security-Enhanced Linux (SELinux) provides a Mandatory Access Control (MAC) system for Linux operating systems. MAC restricts the control users have over the files and directories that they create. SELinux allows files, and therefore everything on a Linux system, to be labeled. This label is called an SELinux context.

For example, run the cd command to change into your home directory, and then run the touch file1 command. Use the ls -Z file1 command to view the SELinux label: 

ls -Z file1
-rw-rw-r--  username groupname user_u:object_r:user_home_t      file1
  • selinux_user_identity: the SELinux user account associated with an object (files) or subject (process). selinux_user_identity defines the owner for an object, and the user a process runs as for subjects. SELinux has a database that maps between SELinux user identities and Linux user identities (semanage login -l).
  • role: attribute for Role Based Access Control. Defines which domains a process can access. RBAC controls domain transitions, such as which SELinux users can exist in which domains.
  • type: defines a type for objects, and a domain for subjects (processes). SELinux policy rules define how domains access types. Default deny: access is only granted if the policy specifically permits it.

Type Enforcement (TE): fine-grained access control. MAC allow/disallow actions are checked after DAC permissions. All Files are labeled with a type. Access is only granted if it is specifically defined - the default action is to deny access. This prevents subjects (processes), such as Samba and FTP, from accessing files they should not have access to, for example, files in user home directories.

Categories: category enforcement for MCS, and security level enforcement for MLS. MCS always uses s0 - you must use MLS for other levels. MCS security level in targeted is at the discretion of the user. In MLS, the security level is mandatory.

<http://www.linuxjournal.com/article/9408>

The SELinux user and role do not effect access control for objects.

Subjects

On an SELinux system, processes, such as a user running the less command, or an Apache HTTP server, are called subjects. An executable file transitions to a process, and a process runs in a domain. When using targeted policy, domains run as the system_r role. Type enforcement then separates each domain.

Object Classes

Object classes group common resources, such as files or processes, together. Each object class has a set of permissions, for example, read is a permission associated to the file object class. For a process, a signal, such as sigkill, is a permission associated to the process object class. Combined with type enforcement, object classes and permissions allow for flexible control over how subjects (processes) access and interact with objects (files). Object classes are important when writing policies, and as such, they are not discussed in detail in this guide.

Targeted Policy Overview

  • Confined and unconfined processes. Explain unconfined.
  • Confined System Domains:
    • httpd - apache man httpd_selinux
    • samba man samba_selinux
    • ftp man ftpd_selinux
    • rsync man rsync_selinux
    • kerberos man kerberos_selinux
    • named man named_selinux
    • nfs man nfs_selinux
    • nis man nis_selinux
    • ypbind man ypbind_selinux

...

  • Confined user domains:
    • Minimal login user - guest_t
    • Minimal X-Windows Login User -xguest_t
    • Standard User Account - user_t
    • Admin User Account - staff_t
    • Unconfined User - Unconfined_t







Working with SELinux

Working with SELinux

Targeted Policy Overview

  • Confined and unconfined processes. Explain unconfined.
  • Confined System Domains
    • httpd - apache
  man httpd_selinux
    • samba
  man samba_selinux
    • ftp
  man ftpd_selinux
    • rsync
  man rsync_selinux
    • kerberos
  man kerberos_selinux
    • named
  man named_selinux
    • nfs
  man nfs_selinux
    • nis
  man nis_selinux
    • ypbind
  man ypbind_selinux

...

  • Confined user domains
    • Minimal login user - guest_t
    • Minimal X-Windows Login User -xguest_t
    • Standard User Account - user_t
    • Admin User Account - staff_t
    • Unconfined User - Unconfined_t

Access Control

Describe the concepts of the following, using <http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/selg-overview.html> as a guide:

  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Multi-Level Security (MLS)
  • Mutli-Category Security (MCS)
  • Type Enforcement (TE)
  • Role Based Access Control (RBAC)

SELinux rules are not checked if DAC rules deny access.

RBAC: Roles are associated with domain types, and domain types are associated with SELinux users. When not taking domain transition into account, roles do not restrict access between subjects and objects, but limit which SELinux users can exist and transition to which domains. For example, domain transition fails if the SELinux user and the new domain type are not allowed to exist in the security context that is created after a domain transition occurs. Roles are important when writing policies, but do not restrict access per se, and as such, are not discussed in detail in this guide.

Retrieved from "https://fedoraproject.org/w/index.php?title=Docs/Drafts/SELinux_User_Guide/SELinux_Content_Specification&oldid=44935"