From Fedora Project Wiki

Revision as of 06:41, 5 August 2008 by Mdious (talk | contribs) (New page: = Rough Notes - not ready to be seen ;) = == Terminology == processes = subjects objects/resources = files, devices, sockets, ports, other processes. processes interact with objects. ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Rough Notes - not ready to be seen ;)

Terminology

processes = subjects

objects/resources = files, devices, sockets, ports, other processes.

processes interact with objects.

selinux_user_identity:role:type

Concepts

- SELinux is built into the kernel, and checks for allow/disallow actions _after_ standard Linux discretionary access control.

- With SELinux, decisions are made from all available information, not just user and group IDs.

- If a user exposes their home directory using chmod, those files still have a (user_home_t?) context. Confined processes can not interact with these unless a specific policy has been written to allow it.

- SELinux confined web server process: attack compromises the web server, but will only have access to the files the web server has access to. Data from other confined processes is not available.

- In SELinux, processes (subjects) live in a domain (a resitrcted sandbox that defines the capabilities of that subject, such as the files it can access). Processes run under the authority of a user (role). The role defines which domains a process may access.

- Each file has a security context: a user identity, a role, and a type:

user_identity:role:type:sensitivity:category

- When a subject, (for example, an application), attempts to access an object (for example, a file), the policy enforcement server in the kernel checks an access vector cache (AVC).

Linux Security Modules (LSM) is a framework that allows the Linux kernel to support a variety of computer security models while avoiding favoritism toward any single security implementation.

LSM inserts "hooks" (upcalls to the module) at every point in the kernel where a user-level system call is about to result in access to an important internal kernel object such as inodes and task control blocks.

persistent security IDs (PSIDs): numerical representations mapped by SELinux to a security context label. Used to be stored in unused field of ext2 inode. Each file had to be modified; then, loadable kernel module stored PSIDs in a normal file, allowing SELinux to support more file systems. This was slow and inconsistent.

Next step, SELinux integrated into the upstream kernel, which has full support for LSMs, and extended attributes (xattrs) in the ext3 file system. SELinux moved to using xattrs for storing security context information (The xattr namespace provides useful separation for multiple security modules existing on the identical system.??)

User Identity and Role

selinux_user_identity:role:type

- user identity: SELinux user account associated with an object (files, sockets, etc) or subject (process). SELinux identities differ from UNIX identities, as they are applied as part of the security label. SELinux uses its own database mapping of SELinux user_identities and Linux users. - roles define which SELinux user identities are permitted access to which domains.

selinux_user_identity: for processes, defines the user account the process runs as. For objects, this defines the owner of the object.

With a process, user_identity is the user account the process runs as.

role: process runs under the authority of a role. A role defines which SELinux users can access which domains. A process runs *as* the SELinux user identity...

Domain / Type

type defines domains for processes, and types for objects.

A domain: a type applied to a process


- processes run in domains. Objects/resources (files, sockets, and so on) are assoicated with a type. - executables transition to processes (subjects)

- objects (resources) live in protected domains called *types*.

example: web server binary type *httpd_exec_t (the protected domain)*, the process belongs to *httpd_t* domain. Data for this server is type httpd_sys_content_t. Policy allows processes (subjects) in httpd_t domain to access files with tpye "httpd_sys_content_t". Different type causes AVC denial

when you run binary (httpd_exec_t), transitions to process (httpd_t domain).

Policy Notes

Policy defines rules that govern how domains can access types, as well as which user identities are allowed to access which roles and domains. Access is only granted if the policy specifically permits it. Types help prevent processes accessing files that they should not. For example, the Apache HTTP process running in the httpd_t domain, can not read or write files in a user's home directory that are labeled with the user_home_t type. When a process running in a domain attempts to read or write to a file that is not labeled with the correct type, an AVC denial message is logged. If auditd is running, a detailed AVC message is written to /var/log/audit/audit.log. If rsyslog is running, an AVC message, although less informative, is also written to /var/log/messages.