SELinux and RHEL4

Thorsten Scherf, Oktober 2005
Red 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

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: EAL3+, COE, Section 508

Develop security features

configuration / hardening tools

Exec Shield

SELinux

increasing number of attacks on Linux Systems

The complexity of OSS deployments is growing rapidly. - With growing problems due to a missing general design.

OSS often lacks architectural stability, development is hard to plan

fixes are often only available for the newest version.

There is a large number of ill supported individual solutions.

The number of security problems in OSS is large – they “just” get fixed in time.

OSS Challenges

Technical dependencies hinder

applying security fixes

Enterprise Linux as a Model

Red Hat Enterprise Linux addresses a number of problems:

Architectural stability – makes OSS predictable

Defined platform, certification, compatibility

„Slowing down” the release cycle – only every 12 – 18 months

Long term support and maintenance (7 years) for each version with backports of security fixes

Provides a predictable platform for ISVs, OSS projects and the user

Resolves the version and certification conflicts

Provides long term security

Red Hat Enterprise Linux model

eliminates hindering problem

Existing OS Security Features

Security features in RHEL 3 and RHEL 4

Standard Linux features (multi user OS, IPTables, etc.)

Signed Packages (RPM)

Posix ACLs

System call auditing

Exec-Shield

stack protection for all CPU types (using NX technology if available)

Stack, heap and shared library position randomization

Position Independent Executables (PIE)

ELF Data Hardening

COE and EAL certification*

* Note however that the EAL level ( like 3+ ) does not necessarily say something about the security of a single instanze of the OS and that a
“higher” EAL level does not mean “more security”.

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 Control

system 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 Control

Once a security exploit gains access to
privileged system components the entire
system is compromised

Domain-Type based Access Control

Kernel policy defines application rights,
firewalling applications from compromising
the entire system

Policy

Enforcement

Userid (UID)

Uid = 0 gives complete control

Uid != 0 still gives almost full 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

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

Executable has SELinux type

Resources have SELinux type

Executable 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

Module

Permits or denies

accesses to

all objects

Process Pa

Process Pb

File Fa

File Fb

Device Da

Device Db

SC

SC

SC

SC

SC

SC

User Ua

SC

User Ub

SC

Subject Requests

Access 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 ...”

Access vectors (rules)

operations on types as granted operations on classes

SELinux Policy components

Examples

Types / Domains

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 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

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

Learning More and Getting Involved

SELinux Guide for RHEL4: http://www.redhat.com/docs

FAQ: http://www.nsa.gov/selinux/FAQ

Tutorial: http://www.coker.com.au/

Fedora: http://fedora.redhat.com

Fedora and selinux: fedora-selinux-list@redhat.com

FAQ: http://fedora.redhat.com/docs/selinux-faq-fc3test2/

Upstream SELinux: http://www.nsa.gov/selinux/

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 Russel Coker, Colin Walters and others.

Questions?

2003-11-04T10:29:46