Security Enhanced Linux

Karl MacMillan

Tresys Technology

kmacmillan@tresys.com

Columbia Area Linux Users Group
Columbia, MD
November 10, 2004

Topics

Overview of SELinux

Why you need Mandatory Access Control

Introduction to SELinux Policies

Overview of Setools

Future directions of SELinux

SELinux Overview

SELinux is an enhacement to standard linux

Enhanced Linux kernel

Modified userland

Only for security aware applications

Works with unmodified binaries

Development toolchain

Introduces strong security to Linux

Flexible mandatory access control

Primary mechanism is Type Enforcement

Complete and proven solution

Can fundamentally solve a many security challenges

SELinux History

Long history

Began as a NSA research project with SCC (DTOS)

Architecture refined at University of Utah (Flask)

Introduced to Linux in 2001

Large kernel patch

Motivated the development of LSM

Integrated into mainline kernel in 2003

First LSM module included in kernel

Present in all 2.6 kernels

SELinux Availibility

Directly from the NSA (http://www.nsa.gov)

Integrated into distributions

Fedora Core 3

Redhat Enterprise Linux 4 (upcoming release)

Hardened Gentoo

Add-on to distributions

Suse 9

Debian

Probably others . . .

Why you need Mandatory Access Control

Review of Access Control Concepts

Reference Monitor Concept

Subjects

Rules
DB

Objects

Active entities

(e.g., executing
programs)

Resources and information

containers (e.g., files, ports,
memory, devices)

Security Policy as

implemented

Review of Access Control Concepts

Reference Monitor Concept

Subjects

Rules
DB

Objects

?

yes/no?

access
attempt

RVM

Review of Access Control Concepts

Reference Monitor Concept

Subjects

Rules
DB

Objects

?

yes/no?

access
attempt

Reference Validation Mechanism

tamperproof

non-bypassable

verifiable

RVM

Kernel

Standard Linux Access Control

Subjects

Rules
DB

Objects

Processes

files, directories,
pipes, devices

Fixed, hard-coded policy rules

access
attempt

open()

Processes

real and effective user and group IDs

File system objects

access modes in inode

Rules DB: Fixed, hard-coded in the kernel

typically checked on open prior to descriptor create

Standard Linux Access Control

rwx r-x --- uid gid

not user or group permissions

group, not user permissions

user permissions

RVM

Kernel (enhanced)

SE Linux Access Control

Subjects

Rules
DB

Objects

Processes

files, directories, pipes,
devices, sockets, etc.

Dynamically Loaded Policy

access
attempt

many sys calls

Types of Access Control

Access Control in general

subjects and objects have security attributes

access determined based on policy rules

Discretionary Access Control

users can change security attributes at request

allowing programs running on behalf of a user to affect the results of access rules

Mandatory Access Control

users cannot change security attributes at request

user programs must work within the constraints of access rules

MAC access rules are controlled by the organization, not the user

Weakness of Discretionary Access Control

Fails to recognize difference between users and programs

processes are user surrogates, can run arbitrary code

processes can change access control attributes

DAC generally assumes benign software environment

Even in benign environments, subject to user arbitrary discretion

Result: much can happen not intended

open to any malicious software (e.g., Trojans)

errors lead to possible great escalation of privilege

no protection against even “trusted” user error

Strengths of Discretionary Access Control

Convenient

easier to use; flexible

users feel like they are in control

allows ownership concept

Simple to understand

software personification

we think programs are really us and will behave as we intend

ownership and user control natural results

Types of Mandatory Access Control

Bell-LaPadula Policy (multilevel security)

access control attributes:

hierarchical security level

set of non hierarchical categories

fixed rules: “no read up, no write down”

(subject)
HIGH SL

(subject)
LOW SL

(object)
HIGH SL

(object)
LOW SL

read
down

read
same

write
up

write
same

write
same

read
same

write
down

read
up

Types of Mandatory Access Control

Biba Integrity model

access control attributes:

hierarchical integrity level

set of non hierarchical integrity categories

fixed rules: “no write up, no read down”

exact opposite of BLP/multilevel security

(subject)
HIGH IL

(subject)
LOW IL

(object)
HIGH IL

(object)
LOW IL

read
same

write
same

write
same

read
same

write
down

read
down

read
up

write
up

Types of Mandatory Access Control

BLP and Biba are commonly implemented MAC

typically both together

strict and inflexible

reflecting the real-world counterparts of classified information

Other MAC policy examples

Chinese Wall (attempt at commercial mandatory security)

non-interference (separation kernel)

some role-based access control policies

Type enforcement ala SE Linux

general purpose policy language

flexible and highly configurable

extremely granular

yet still mandatory security

Introduction to SELinux Policies

Type Enforcement Access Control

Access specified between subject type (domain) and object type

Four elements in defining allowed access

source type(s)	aka domain(s)

target type(s)	objects to which access allowed

object class(es)	classes to which access applies

permission(s)	type of access allowed

All access is denied unless explicitly allowed

Object Classes and Permissions

SE Linux currently defines 29 kernel object classes

1) security	2) process	3) system	4) capability
5) filesystem	6) file	7) dir	8) fd
9) lnk_file	10) chr_file	11) blk_file	12) sock_file
13) fifo_file	14) socket	15) tcp_socket	16) udp_socket
17) msgq	18) sem	19) msg	20) shm
21) ipc	22) node	23) netif	24) netlink_socket
25) packet_socket	26) key_socket	27) rawip_socket
28) unix_stream_socket	29) unix_dgram_socket

Each with their own fine-grained permissions

For example, file object class has 19 permissions:
ioctl	read	write
create	getattr	setattr
lock	relabelfrom	relabelto
append	unlink	link
rename	execute	swapon
quotaon	mounton	execute_no_trans
entrypoint

Simple TE Allow Statement

allow user_t bin_t : file { read execute } ;

object class

permissions

object type

domain type

Translation: A process with type user_t can read or execute files of type bin_t

user_t

subject

bin_t

object

read

execute

write

passwd Program Example

allow passwd_t shadow_t : file
{ create ioctl read getattr lock write setattr append link unlink rename };

Allows processes with passwd_t domain type read, write, and create access to files with shadow_t type

Purpose: passwd program runs with passwd_t type, allowing it to change shadow password file (/etc/shadow)

Shadow password file attributes:

-r-------- root root system_u:object_r:shadow_t /etc/shadow

standard Linux

SE Linux

only allows root to create
new copies of file
(via uid==0 privilege)

only allows passwd_t domain (via above allow rule) to modify file

passwd Program Example

euid: root
passwd_t

passwd

r-------- root root
shadow_t

/etc/shadow

write, create, …
(change password)

allow passwd_t shadow_t : file
{ read getattr write setattr append };

Problem of Domain Transitions

euid: root
passwd_t

passwd

r-------- root root
shadow_t

/etc/shadow

write, create, …
(change password)

uid:joe
euid: joe
user_t

login

bash

allow passwd_t shadow_t : file
{ read getattr write setattr append };

write,…

?

Standard Linux passwd Security

uid: joe
euid: joe

r-------- root root

/etc/shadow

uid: joe
euid: joe

login

bash

r-s--x--x root root

/usr/bin/passwd

fork()

execve()

bash

passwd

Anyone can execute

Standard Linux passwd Security

uid: joe
euid: joe

r-------- root root

/etc/shadow

write, create, …
(change password)

uid: joe
euid: joe

login

bash

r-s--x--x root root

/usr/bin/passwd

fork()

execve()

passwd

Standard Linux passwd Security

uid: joe
euid: joe

r-------- root root

/etc/shadow

uid: joe
euid: joe

login

bash

r-s--x--x root root

/usr/bin/passwd

fork()

set uid

bash

execve()

Standard Linux passwd Security

uid: joe
euid: root

r-------- root root

/etc/shadow

uid: joe
euid: joe

login

bash

r-s--x--x root root

/usr/bin/passwd

fork()

passwd

set uid

write, create, …
(change password)

execve()

SE Linux Domain Transitions

uid: joe
euid: joe

r-------- root root

/etc/shadow

uid: joe
euid: joe

login

bash

r-s--x--x root root

/usr/bin/passwd

fork()

bash

shadow_t

user_t

user_t

passwd_exec_t

SE Linux Domain Transitions

uid: joe
euid: joe

r-------- root root

/etc/shadow

uid: joe
euid: joe

login

bash

r-s--x--x root root

/usr/bin/passwd

fork()

bash

shadow_t

user_t

user_t

passwd_exec_t

execve()

allow user_t passwd_exec_t : file { getattr execute };

SE Linux Domain Transitions

uid: joe
euid: root

r-------- root root

/etc/shadow

uid: joe
euid: joe

login

bash

r-s--x--x root root

/usr/bin/passwd

fork()

shadow_t

user_t

user_t

passwd_exec_t

execve()

allow user_t passwd_exec_t : file { getattr execute };

write, create, …
(change password)

passwd

SE Linux Domain Transitions

uid: joe
euid: root

r-------- root root

/etc/shadow

uid: joe
euid: joe

login

bash

r-s--x--x root root

/usr/bin/passwd

fork()

shadow_t

user_t

passwd_t

passwd_exec_t

execve()

allow user_t passwd_exec_t : file { getattr execute };

write, create, …
(change password)

passwd

allow user_t passwd_t : process transition;

allow passwd_t passwd_exec_t : file entrypoint;

type_transition user_t passwd_exec_t : process passwd_t;

Type Transition Statement

First form: default domain transition

Causes a domain type transition to occur on execve()

Does NOT allow it!

type_transition user_t passwd_exec_t : process passwd_t;

object
(process for domain trans)

source
domain

file type of
executable

new type
for process

passwd_t

passwd_exec_t

execve()

user_t

1

2

Why Type Enforcement

Extremely configurable mandatory access control

flexible (not tied to a single security objective)

dynamic (loadable policy)

possible to be pragmatic within a policy

even necessary due to Linux legacy!

fine-grained access control

object classes and permissions, unlimited types and rules

Useful for a large number of security goals and objectives

Challenges with SE Linux

Policies are usually complex

legacy issues with Linux/Unix

need for pragmatism

Flexibility comes with a price!

tens object classes, over a hundred permissions

any number of object instances

unlimited domain and object types

Assurance of mechanism untested in traditional manner

open source model helps

certainly no worse than Linux (or other mainstream OSs)

in fact much better with a good TE policy

Tresys SeTools

SeTools Background

Motivation

TE policy analysis

security evaluation and certification

TE policy development

writing policies

debugging policies (related to analysis)

TE policy management

Evoluationary development, GPL source code

www.tresys.com/selinux

also in NSA distribution
(sourceforge.net/projects/selinux)

SeTools Overview

Apol: Policy analysis/debug tool

allows analysis of policy via policy.conf

all major policy components; search and find

emerging automated analyses

information flow and domain transition

SePCuT: Policy custimization, basic editing

SeUser: Example user manager for SELinux

command line and GUI

SeAudit: audit message analyzer

Misc. command line tools in progress

SeTools Demonstration

QUESTIONS?

Karl MacMillan

Tresys Technology

kmacmillan@tresys.com

selinux@tresys.com

135 minutes (2 hours 15)

[2/11: 75 minutes]

[2/19: 95 minutes]

30 minutes

[2/11: 50 minutes]

[2/19: 50 minutes]

Note that in standard Linux there is no access control to sockets except for limiting raw access to root.

SE Linux provides security decisions and enforcement on every call, while standard Linux applies the security check only on open.

NOTE AT END OF THIS SLIDE: SELinux has experimental BLP-like access control mechanisms which optional. Not included in this course, and indeed not as useful as other mechanisms.

Note that the Biba integrity model is orthogonal to the Bell-LaPadula multi-security level model. The objects and subjects on this slide are different colors to emphasize this point.

Note that today’s system violate no write-down and use trusted applications which lowers assurance.

May want to include a description of the access vector matrix prior to this slide (new slide?)

Note that standard Linux does not provide control over all objects. SE Linux provides both granularity and completeness.

A policy writer can’t change these object classes or permissions, but they will evolve over time, so it is important to keep up with what is happening in the SE Linux model.

Common permissions order the permissions to ensure the same permission bit means the same thing—this enables the kernel to check a specific bit for a specific permission without a lookup.

This is a simplistic view of read and execute—additional permissions are required to actually perform these actions.

Note that changing a password is actually a transactional process—passwd creates a new file, creates a hard link to the old shadow password file, then renames the new file. This protects against corruption if the process is interrupted for some reason.

Note that the standard Linux kernel never sees the username—only the uid.

Entrypoint – can only enter from;

Transition control –can enter

These permissions extend control over execution.

PowerPoint Presentation

1600-12-31T19:00:00