SELinux Overview DAC vs MAC Discretionary Access Control Mandatory Steve Musacchia smxsteve@yahoo.com

SELinux Books

SELinux History Not going to talk much about the history. “Look it up” Except to say that since the 70's various forms of computer security have been developed. One of which is “type” enforcement. Early systems were the “LOCK” system and later the “FLASK” OS. The NSA was involved and wanted the technology of FLASK to be available in a mainstream OS -- SELinux was born – first patches going into the 2.2.x kernel.

SELinux's main concept To access objects, the subjects type must be authorized for the objects type, regardless of the identity of the subject. OK!

Objects Subjects SELinux Concepts * Files * Sockets * Interprocess Communications * Network Hosts * ... Subjects * Processes

Security Contexts SELinux Concepts * Everything (subjects and objects) have a single scontext associated with it. * scontexts have 3 elements user : role : type

Security Contexts SELinux Concepts * Of user : role : type, Very important * Of user : role : type, The type identifier is the primary part that is used to determine access. * A subjects type is called a “domain”. I quote from the book... (process) “For historical reasons, the type of a process is called a domain. The use of “domain” and “domain type” to mean the type of a process is so common and pervasive that we do not attempt to avoid using the term domain. In general, consider domain, domain type , subject type, and process type to be synonymous.

Security Contexts SELinux Concepts What do they look like in real life? Path Name Security Context ------------------------------------------------------------------------------------- /bin system_u : object_r : bin_t /usr system_u : object_r : usr_t /bin/passwd system_u ; object_r : passwd_exec_t /root/.bash_history root : object_r : user_home_t /var/www system_u : object_r : httpd_sys_content_t /var/lib system_u : object_r : var_lib_t Notice that they all have a suffix of either _u, _r or _t Notice that system_u and object_r get repeated a lot.

Security Contexts SELinux Concepts An actual directory listing of / on Fedora7 drwxr—xr-x root root system_u:object_r:bin_t bin drwxr-xr-x root root system_u:object_r:boot_t boot drwxr-xr-x root root system_u:object_r:device_t dev drwxr-xr-x root root system_u:object_r:etc_t etc drwxr-xr-x root root system_u:object_r:home_root_t home drwxr-xr-x root root system_u:object_r:lib_t lib drwx------ root root system_u:object_r:lost_found_t lost+found drwxr-xr-x root root system_u:object_r:mnt_t media drwxr-xr-x root root system_u:object_r:autofs_t misc drwxr-xr-x root root system_u:object_r:mnt_t mnt drwxr-xr-x root root system_u:object_r:autofs_t net drwxr-xr-x root root system_u:object_r:usr_t opt dr-xr-xr-x root root system_u:object_r:proc_t proc drwxrwxrwx root root system_u:object_r:tmp_t public drwxr-x--- root root root:object_r:user_home_dir_t root drwxr-xr-x root root system_u:object_r:bin_t sbin drwxr-xr-x root root system_u:object_r:security_t selinux drwxr-xr-x root root system_u:object_r:var_t srv drwxr-xr-x root root system_u:object_r:sysfs_t sys drwxrwxrwt root root system_u:object_r:tmp_t tmp drwxr-xr-x root root system_u:object_r:usr_t usr drwxr-xr-x root root system_u:object_r:var_t var

-Z Security Contexts SELinux Concepts Some commands modified to support SELinux -Z A new option: Displays security contexts

ls -Z id -Z ps -Z Security Contexts SELinux Concepts Commands modified to support SELinux ls -Z id -Z ps -Z even cp -Z Others ...

Security Contexts - Filesystems SELinux Concepts Security Contexts - Filesystems Filesystems must support “extended attributes” The security context is stored in the extended attributes capability of the filesystem. Ext2/3/4 are known to work. Reiser 3 – not sure – I don't think it does. Reiser 4 – I believe it does XFS does work. Not sure about others.

Security Contexts - Mounts SELinux Concepts Security Contexts - Mounts A single scontext is applied to the mount point of a filesystem that does not support scontexts so the whole thing has 1 scontext. There may be other ways to handle scontexts that I don't know about for mounted filesystems of various types.

Major Policy choices SELinux Concepts There are 2 Major Policy Selections in SELinux Strict Policy - Just what is says strict and unforgiving Targeted Policy - Much easier to deal with. By default RHEL and Fedora use the Targeted Policy. Fedora Core 2 came out with the Strict policy and most people couldn't handle it. They just had to turn it off.

Modes of Enforcement SELinux Concepts There are 3 Modes of Enforcement in SELinux 1. Disabled - Just turn it off. 2. Permissive - On but just logging accesses. 3. Enforcing - Accesses blocked and logged.

Commands of SELinux (some) SELinux Concepts Commands of SELinux (some) sestatus information about the current state. getenforce get the enforcement mode. setenforce change the enforcement mode. chcon change the scontext of object runcon run in a different scontext fixfiles reset scontexts on files restorecon similar to above (some overlap) setfiles used for larger changes. newrole change role

SELinux and Linux Permissions SELinux Concepts SELinux and Linux Permissions Linux permissions... are still in effect. are consulted first; if standard linux permissions would not allow access then access is denied without even consulting SELinux. So SELinux can allow access but that's not enough.

-------------------------------------- There is NO default superuser SELinux Concepts SELinux Default Access Rule ACCESS DENIED All access must be explicitly granted. SELinux allows no access by default regardless of the Linux user/group ID -------------------------------------- There is NO default superuser

Type enforcement access control SELinux Concepts Type enforcement access control The way access is granted is by specifying access from a subject type and an object type using an “allow” rule. An allow rule has 4 elements. 1. Source type Usually the domain type of a process attempting access. 2. Target type The type of an object being accessed by the process. 3. Object Class The class of object that the specified access is permitted. 4. Permissions The kind of access that the source type is allowed to the target type for the indicated object class

Type enforcement access control SELinux Concepts Type enforcement access control An example allow rule: allow user_t bin_t : file { read execute getattr } Subject = user_t Object = bin_t Class = file Permissions = read execute getattr Translation: A process with a domain type of user_t can read, execute, or get attributes for a file object with a type of bin_t

A problem to be solved: SELinux Concepts Joe needs to change his password. I.E. Modify the /etc/shadow file. Normally he can do this because passwd is setuid root. But, that means the passwd program can, if corrupted, modify any file on the system because it runs as root! In fact, any program run by root can potentially modify any file on the system.

Type enforcement Example SELinux Concepts Type enforcement Example The start of a solution would be to label the /usr/bin/passwd program to a certain type, say passwd_t and label the /etc/shadow file with shadow_t and create an allow rule like this: allow passwd_t shadow_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename } Translation: A process with a domain type of passwd_t can read, execute, blah, blah, blah, ... a file object with a type of shadow_t

Type enforcement Example SELinux Concepts Type enforcement Example ls -Z /etc/shadow -r-------- root root system_u:object_r:shadow_t shadow ps -aZ joe:user_r:user_t 16532 pts/0 00:00:00 bash ls -Z /usr/bin/passwd -rwsr-xr-x root root system_u:object_r:passwd_exec_t passwd allow passwd_t shadow_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename } That allow rule is not enough – there has to be more to it. There is!

Domain Transitions SELinux Concepts execve() is the only way to change a domain type.

Domain Transitions SELinux Concepts Super Important allow passwd_t passwd_exec_t : file entrypoint This rule defines which executable may “enter” a domain. For a Domain Transition, the new (to-be-entered) domain must have entrypoint access. Here, passwd_t is to-be-entered. With this, we have a situation that only the password program can run in the passwd_t domain type. “This is powerfull security control.” Super Important

Domain Transitions SELinux Concepts allow user_t passwd_t : process transition; Notice that this is the first allow rule that has “process” instead of “file” as it's object class. The 3 rules together provide access for a domain transition to occur. For domain transition to succeed, all 3 are necessary; not one alone is sufficient.

SELinux Concepts Domain Transitions

Domain Transitions SELinux Concepts The following 3 things must be true for a domain transition to occur 1. The process' new domain type has entrypoint access to the executable file type. 2. The process' current (or old) domain type has execute access to the entrypoint file type. 3. The process' current domain type has transition access to the new domain type.

Domain Transitions Um, one more thing... SELinux Concepts To support domain transitions occurring by default, we need one more rule. type_transition user_t passwd_exec_t : process passwd_t