SELinux im Einsatz

HP User Society / DECUS16. Mai 2006

Joachim SchröderRed Hat GmbH

Security Basics Security problem / attack types

exploit (buffer overflows) virus (damage and distribute via local files) worm (damage and distribute via network daemons)

Results data compromise, modification, loss resource misuse (cost & legal consequences) operational costs

Reasons broken software misconfigured systems odd user action technical dependencies can hinder deployment of fixes

Security is a technical issue— New technology can make systems more impervious to common attacks by default. It can also provide organizations with more control over who can access which resources.

Security is a human issue— Compliance and failure to keep systems up to date are a major source of security vulnerabilities. Administrators need help understanding the state of their systems and managing the complexity of securing their network.

Security is an economic issue— In an interconnected environment, you are only as secure as your neighbour. Access to strong security must be affordable enough to be ubiquitous.

Aspects of the Security Problem

An Abstract Security Model Subject

user ID process / thread

Object system resources filesystem, file, directory network socket, port kernel module, setting

Runtime context process thread

Security permissions allow/deny and audit/dontaudit (combinable)

Linux Security Status Security technology

UNIX security model file permissions per uid/gid root-only actions chuid/chgid and setuid/setgid programs UNIX process separation

Hardening technologies chroot environments pluggable authentication modules (PAM) firewalling

Result no viruses no significant worms Linux systems easy to secure

Red Hat Security Activities Enterprise Linux model

backport fixes into existing code tree eliminate Open Source Software challenges

Red Hat Network efficient deployment of relevant errata

Red Hat Security Response Team single point of contact coordinate fix testing with partners track known problems and solutions in public database

Security certifications: EAL 3+ & 4+, COE, Section 508 Develop security features

configuration / hardening tools Exec Shield SELinux

Is this enough? Solves the version and certification conflicts. Solves the fix deployment problem to a good part. Reduces the buffer overflow problem But what, if an attack is successful? What about misconfiguration? What about treacherous users?

Objective: Reduce the remaining risk by limiting the potential damage caused by the failure of these security mechanisms

A Mandatory Access Controlsystem is needed

Security Enhanced Linux A system for Mandatory Access Control (MAC) based on the

Linux Security Modules (LSM) framework, integrated in 2.6 Separates system in security contexts, enforced on kernel level Uses features of role-based and domain-type access control Defines transition rules between domains, tracks user identity,

and removes the power of UID 0

Kernel Kernel

Classical UID based Access ControlOnce a security exploit gains access to

privileged system components the entiresystem is compromised

Domain-Type based Access ControlKernel policy defines application rights,

firewalling applications from compromisingthe entire system

Policy

Enforcement

Userid (UID) Uid = 0 gives complete control Uid != 0 still gives a lot of control: access only limited on filesystem

and some ressource interfaces. (e.g. networking, system information) Chroot – a restricted filesystem namespace setuid/setgid binaries: mount, passwd, ping File permissions and ACL

Permissions and ACLs of roughly about 90k (Server) -170k (Workstation) files and directories in an average Linux installation

Current Linux Security Model

Virtually any compromise or miscon-figuration of the above can easily lead to total system compromise

Programs have full control over the access given to files they create (DAC)

Therefore no protection against malicious software, “ social engineering” , and bugs in privileged software which may result in the software granting inappropriate access to files (EG creating a mode 777 file in /tmp)

Too coarse-grained - root vs non-root gives boolean security model for many cases

Security model does not allow tracking of identity across change of UID

What is wrong with Unix security?

Discretionary versus Mandatory Discretionary Access Control – The owner of an object

defines access to it This is the current Linux model chmod, open, rename, write, ptrace (!)

Mandatory Access Control – Security is defined by a centralized policy Policy cannot be overridden either accidentally or deliberately by

malicious software and users Prevents information leaks or privilege escalation even from

accidental misconfiguration Security administrator can ensure two domains never interact, even

if they're both compromised For example, the web server and your raw database

Policy is centralized, which allows for easy analysis Allows protection against untrusted code

SELinux Implements MAC via a combination of methods

Type Enforcement Role-Based Access Control SELinux user identity

SELinux model is independent of normal Linux model, checked after normal Linux checks

SELinux is NOT a different version of Linux – It is integrated in the mainstream kernel 2.6

Policies define what SELinux does. They are written in M4, compiled, loaded into the kernel

Type Enforcement Every process has a domain, every object (file, directory, socket, etc) 

has a type.  The domains are a sub­set of the types (IE types that can apply to processes).

The number of domains can be varied according to needs, having a single domain would give the same result as a non­SE system.  The more domains the mode detailed the control you have over security and the more work to set it up.

The domain of a process will be used as a target context for operations such as sending signals

The domain of a process may be changed at exec time either automatically through policy or through code in login type programs

Different domains have different access rights, no domain is required to have a superset of the access of other domains

Each role has a list of domains that may exist in it At login time the security context is changed (identity, role, 

and domain), also the newrole program may be used to change roles (comparable to an su operation)

A role doesn’t often change, unlike the domain which may change often automatically without the user noticing

The role determines which domains are permitted Roles may also be changed through role_transition rules in 

some situations, this is currently only used for the administrator to launch daemons

Role Based Access Control

Identities The Identity is usually the Unix account name and is 

compiled into the policy database Identity controls the available roles which controls 

the available domains – but this level of control is not used much in the Targeted policy

SELinux – Technical Overview Implemented in Linux Kernel

Linux Security Modules Restrictive controls only In Linux 2.6 integrated

Flask infrastructure policy enforcement security server access vector cache (avc)

Security model - Policy Process has a SELinux domain Objects / resources have SELinux type Executable / processes transitions into domain (attached type &

role) Rules grant or deny domain access to types (resources)

SELinux – How it works 

SELinux Kernel

Security Policy

Security Enforcement 

ModulePermits or denies 

accesses to all objects

Process Pa

Process Pb

File Fa

File Fb

Device Da

Device DbSC

SC

SC

SC

SCSC

User Ua SC

User Ub SC

 

Subject RequestsAccess to File or 

Device

 

Permission Granted to 

Object

Permissive versus Enforcing SELinux can run in 3 modes: Permissive mode

Policy loaded Auditing enabled No denial, only logging Useful for policy writing and troubleshooting

Enforcing mode Policy loaded Auditing enabled Action denial or grant depending on policy

Disabled Policy not loaded No auditing

Only enforcing mode provides more security

Defines whole security model Class declarations with their operations Type declarations of system resources Role declarations Domain transitions Access vectors: operations on types as granted operations on classes

Written at a high level with M4 macros Compiled into a binary form that is understood by the kernel Loaded by /sbin/init at the start of the boot process before any

other programs are executed A modified policy can be loaded at any time by the

administrator

SELinux Policy

Types type declarations can use attributes (derives rules) type assignments rules for filesystems, files and directories

Roles & Identities roles and domains permitted to enter user and roles permitted to enter

Domains domain transition rules type transition rules (newly created files) “ type executed in domain ... transitions into domain ...”

SELinux Policy components

Examples Types

user_t, init_t, dns_port_t Policy specifies which permissions are allowed

allow type1 type2:class { perm1 perm2 ... };

Examples: allow user_t proc_t:file { getattr read }; allow sysadm_t user_t:process { ptrace }; allow named_t dns_port_t:udp_socket { name_bind }; allow sendmail_t bin_t:dir { getattr search };

Examining types[root@nexus bob]# ls -dZ /home/bob

drwx--x--x bob bob system_u:object_r:user_home_dir_t /home/bob

[bob@nexus]# ps -Z

LABEL PID TTY TIME CMD

user_u:system_r:user_t 3722 pts/4 00:00:00 zsh

user_u:system_r:user_t 4135 pts/4 00:00:00 ps

● The 3rd part (e.g. user_home_dir_t) is the type

SELinux policy writing work flow Write policy files

Declare types, domains & roles Define file locations for type assignment Define access rules

Compile policy resulting binary contains all declarations and rules

Label filesystem assign security context to existing files according to policy

Enable Selinux – may require reboot Load policy Run secured program Watch Audit log (/var/log/audit/audit.log)

Startup

SELinux in action

Oct 25 11:53:28 xavier kernel:  audit(1098719608.033:0): avc: denied  { getattr } for pid=6762 exe=/usr/sbin/httpd   path=/home/kmacmillan/public_html dev=dm­0   ino=11897405  scontext=root:system_r:httpd_t   tcontext=user_u:object_r:user_home_t    tclass=dir 

SELinux Implementation in RHEL Integrated into standard RHEL versions – full ISV support

=> Mainstream! Not only the code but actual policies:

Targeted policy in core product secures key network-facing services with minimal system impact

Support for strict (government/military/financial/etc. application) and custom policies through Red Hat Global Professional Services

OS integration Integrated into system boot Policy information gathering, analyse, compiling tools Changed programs for role support: su, login, pam etc. Changed programs for type & domain support: ls, find, id (-Z) Simplified policy management

system-config-securitylevel set booleans instead of policy writing

Documentation & Support

System­config­securitylevel 

Strict Versus Targeted Strict policy

All processes, including user logins, run in restricted domain; again, any interaction not explicitly permitted is denied

Restricting system heavily - not shipped with RHEL

Targeted policy Only certain key system daemons confined by SELinux denial rules

Everything else runs as unconfined_t, a domain which is granted essentially every SELinux permission

Goal is to restrict above daemons, not protect them against the rest of the system

Examining Targeted Policy Currently protected daemons:

dhcpd, httpd, named, nscd, ntpd, portmap, snmpd, squid, syslogd, mtas, mailman, mysql, postgresql, winbind, ypbind

More can be added Use of policy booleans allows dynamic reconfiguration

Disable protection for squid, disable httpd's ability to read user home directories

No extensive use of roles

Case Study: Apache Policy Several virtual hosts, each one managed by a particular

user Users can run arbitrary CGI scripts Need to secure users from each other

Using suexec so CGI scripts run as user uid Need to protect user home directories from compromised

CGI scripts Need to secure system from the users

Applying SELinux Define domain for main webserver (httpd_t), as well as

domain for CGI scripts to run in (httpd_user_script_t) Define types for web content

httpd_sys_content_t, httpd_user_content_t, httpd_user_script_exec_t, httpd_user_script_ro_t

Write policy to define interactions between those types

Filesystem Layout Users maintain sites under /var/www/<site>:

$ ls -dZ /var/www

drwxr-xr-x sam sam system_u:object_r:httpd_user_content_t /var/www/example.com

drwxr-xr-x jane jane system_u:object_r:httpd_user_content_t /var/www/example.org

Static content:$ ls -dZ /var/www/example.com

drwxr-xr-x sam sam system_u:object_r:httpd_user_content_t /var/www/example.com/index.html

drwxr-xr-x sam sam system_u:object_r:httpd_user_content_t /var/www/example.com/about.html

drwxr-xr-x sam sam system_u:object_r:httpd_user_content_t /var/www/example.com/sam.png

Filesystem Layout (contd.)CGI scripts:$ ls -dZ /var/www/example.org

drwxr-xr-x jane jane system_u:object_r:httpd_user_script_exec_t /var/www/example.org/wiki.cgi

drwxr-xr-x jane jane system_u:object_r:httpd_user_script_rw_t /var/www/example.com/wiki.db

drwxr-xr-x jane jane system_u:object_r:httpd_user_script_ro_t /var/www/example.com/intro.html

Home directory:$ ls -dZ /home/jane

drwxr-xr-x jane jane system_u:object_r:user_home_dir_t /home/jane

Security Gained httpd_user_script_t has no permissions to read or write

contents of the users dir home dir with type user_home_dir_t, even though they are owned by the same uid

Compromise of CGI script only means compromise of httpd_user_script_rw_t data

Can go even further and define separate types for different CGI scripts

Example from the Strict Policy Sometimes it is required that an application which is run by a

user have a different security context. For example GPG runs in a different domain so that the main

user domain can’ t access the secret key (to make it harder to steal the key).

If the user executes gpg an automatic transition to the user_gpg_t from user_t takes place:

domain_auto_trans($1_t, gpg_exec_t, $1_gpg_t) GPG files are protected so only the GPG binary executed by

the individual owner is allowed to access the files. The user can not overrride this.

Case Study: GPG

Key Points SELinux provides a secondary, independent layer of

mandatory security Choice of targeted versus strict policy, as well as policy

booleans allows great flexibility Integrated and on by default in Fedora Core 3 and RHEL 4 Extensive documentation and active mailing lists SELinux provides – in difference to other commercial

aproaches – a highly flexible security framework In general applications work WITHOUT modifications Red Hat is the first to provide an enterprise level supported

SELinux solution. Security in RHEL becomes mainstream

More to come Modularized Policy

● RPMS can bring with them their own Policy Multi­Level Security

● hierarchical structures● objects and subjects are labeled with Security Levels 

(sensitivity & category)● very special

Multi­Category Security● simplifying MLS● 128 defineable categories● allows users to label files with categories

Learning More and Getting Involved SELinux Guide for RHEL4: http://www.redhat.com/docs Fedora: http://fedora.redhat.com Fedora and selinux: fedora-selinux-list@redhat.com Release FAQ of FC3&FC4 Inofficial SELinux FAQ

http://www.crypt.gen.nz/selinux/faq.html Tutorial: http://www.coker.com.au/selinux/ (pers. website) Upstream SELinux: http://www.nsa.gov/selinux/ FAQ: http://www.nsa.gov/selinux/FAQ SELinux mailing list: selinux@tycho.nsa.gov M4 tutorial: http://www.cs.utah.edu/dept/old/texinfo/m4/m4.html

This presentation is partly based on materials from Russell Coker, Colin Walters and others.

Questions?

Vielen Dank!

Joachim Schröder, Solution Architectjoachim.schroeder@redhat.com