SELinux Policy Concepts and Overvietrj1/cse543-f07/slides/03-PolicyConcepts.pdf · SELinux Policy...

© 2002 - 2005 Tresys Technology, LLC (www.tresys.com/selinux, [email protected]) 1

SELinux Policy Concepts and Overview

Security Policy Development Primer for Security Enhanced Linux

(Module 3)


SELinux assigns subject and objects a security context:

Access Control Attributes

root:sysadm_r:sysadm_t[:s0:c0.c128]

type identifierrole identifieruser identifier

Security context is only access control attribute in SELinuxSecurity Identifier (SID): number represents security context active within the kernel

mls identifier


Standard Linux vs SELinux

Subject (Process) Access Control AttributesLinux: real and effective user and group IDsSELinux: security context (user:role:type)Linux UIDs and SELinux UID are independent

Objects Access Control AttributesLinux: (files) access modes (rwx r-x r-x) and user and group IDsSELinux: security context (user:role:type)


More on Security Contexts

Linux and SELinux access controls are orthogonaleach mechanism uses its own access control attributes

two separate access checks; both must pass

A process type is also called a “domain”though object and subject contexts are identical

Role and user are little used on objectsobjects’ role usually “object_r”

Type is most used part of a context (by far) in policiesemphasis on type enforcement in a policy


What is a Type?

A type is an unambiguous identifiercreated by the policy writerapplied to all subjects and objects and for access decisions

Types group subjects and objectssignifies security equivalenceeverything with the same type has the same accesspolicies have as few or as many types as needed

Type “meaning” created through usee.g. shadow_t only has meaning because of a policy rulessimilar to a programmer giving meaning to variables


Type Enforcement Access Control

Access specified betweensubject type (e.g., process or domain)

and object type (e.g., file, dir, socket, etc.)

Four elements in defining allowed accesssource type(s) aka domain(s)target type(s) objects to which access allowedobject class(es) classes to which access appliespermission(s) type of access allowed

SELinux prevents access unless explicitly allowed


SELinux defines 41 kernel object classes

Each with their own fine-grained permissionsFor example, file object class has 20 permissions:

ioctl read writecreate getattr setattrlock relabelfrom relabelto append unlink link rename execute swaponquotaon mounton execute_no_transentrypoint execmod

Documentation available at www.tresys.com/selinux

Object Classes and Permissions

key_socketunix_stream_socketrawip_socketnetlink_nflog_socketipcunix_dgram_socketprocessnetlink_kobject_uevent_socketfilesystemudp_socketpasswdnetlink_ip6fw_socketfiletcp_socketpacket_socketnetlink_firewall_socketfifo_filesystemnodenetlink_dnrt_socketfdsocketnetlink_xfrm_socketnetlink_audit_socketdirsock_filenetlink_tcpdiag_socketnetifchr_fileshmnetlink_socketmsgqcapabilitysemnetlink_selinux_socketmsgblk_filesecuritynetlink_route_socketlnk_fileassociation


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 SELinux

only root allowed to create new copies of file

only allows passwd_tdomain (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


uid:joeeuid: joe user_t

login

bash

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

write,…

?


Standard Linux passwd Security

uid: joeeuid: joe

r-------- root root

/etc/shadow

uid: joeeuid: joe

login

bash r-s--x--x root root

/usr/bin/passwd

fork()

execve()

bash passwd

Anyone can execute



uid: joeeuid: joe

r-------- root root

/etc/shadow


uid: joeeuid: joe

login


/usr/bin/passwd

fork()

execve()

passwd



uid: joeeuid: joe

r-------- root root

/etc/shadow

uid: joeeuid: joe

login


/usr/bin/passwd

fork()

set uid

bash

execve()



uid: joeeuid: root

r-------- root root

/etc/shadow

uid: joeeuid: joe

login


/usr/bin/passwd

fork()passwd

set uid


execve()


SELinux Domain Transitions

uid: joeeuid: joe

r-------- root root

/etc/shadow

uid: joeeuid: joe

login


/usr/bin/passwd

fork() bash

shadow_tuser_t

user_t

passwd_exec_t



uid: joeeuid: joe

r-------- root root

/etc/shadow

uid: joeeuid: joe

login


/usr/bin/passwd

fork() bash

shadow_tuser_t

user_t

passwd_exec_t

execve()

allow user_t passwd_exec_t : file { getattr execute };



uid: joeeuid: root

r-------- root root

/etc/shadow

uid: joeeuid: joe

login


/usr/bin/passwd

fork()

shadow_tuser_t

passwd_t

passwd_exec_t

execve()

type_transition user_t passwd_exec_t : process passwd_t;allow user_t passwd_exec_t : file { getattr execute };


passwd

allow user_t passwd_t : process transition;allow passwd_t passwd_exec_t : file entrypoint;


Type Transition Statement

First form: default domain transitionCauses a domain type transition to be attempted on execve()

type_transition user_t passwd_exec_t : process passwd_t;

object (process for

domain trans)

sourcedomain

file type ofexecutable

new typefor process

passwd_t passwd_exec_texecve()

user_t1

2


Type Transition Statement

type_transition specifies default transitionDoes NOT allow it!Successful domain trans. requires access allowed

original domain execute access to executable fileoriginal domain permission to transition to new domainnew domain permission to be entered via programothers...

Second form: default object types on creation to be discussed in later modules


The Role of Roles

Roles associates domains with usersfurther constrains process type transitions

process type allowed only if allowed by role definitioneven if type enforcement allows it

Role declaration statement

role user_r types passwd_t;

allowed type

role for which type is allowed


Roles in Domain Transitions

r-------- root root

/etc/shadow

login


/usr/bin/passwd

fork()

shadow_t

user_r:user_t

user_r:passwd_t

passwd_exec_t

execve()

write, setattr, …(change password)

role user_r types passwd_t;

passwd


Why Type Enforcement

Extremely configurable mandatory access controlflexible (not tied to a single security objective)dynamic (loadable/conditional 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


Security Goals TE can Implement

System integrity, RVM/kernel self-protectionraw devices and resourceskernel configuration and binary files (e.g., modules)daemon/services configuration and binary filesprotection of SELinux policy itself

Application integrityconfiguration and binary filesinter-process communication

Least privilegepreventive security engineering designprotection of privileged user environments


Security Goals TE can Implement

Controlled execution domainsisolation of untrusted code (e.g., sandboxes)prevention of malicious code in trusted domains

System Hardeningconfinement of error propagation (exploitations)fine-grained access control

Domain isolationtrusted from untrustedapplication from application

Information flow policiesMultilevel security and multiple security levelsGuards and other cross-domain solutionsPerimeter defense


Challenges with SELinux TE

Policies are usually complexDue to complexity of Linux kernel

legacy issues with Linux/Unixneed for Pragmatism

Flexibility comes with a price!41 kernel object classes, hundreds of permissionsthousands of object instancesunlimited domain and object types

Assurance of mechanism evolvingopen source model helpscertainly no worse than Linux (or other mainstream OSs)in fact much better with a good TE policy


Policy Concept Overview Summary

Standard Linux and SELinux access control mechanisms are orthogonalSELinux security context: user:role:type

applied to both objects and subjectstype is the primary means of controlling access

Fine grained access control41 kernel object classes, hundreds of permissions

Access must be explicitly allowed in TE policyall access denied by default


Policy Concept Overview Summary

TE allow statement: allow domain_type object_type: classes permission ;specifies allowed access based on types

TE domain transition:changing of process type (domain) on execve()type_transition specifies default transition

Type enforcement flexiblecan implement many security properties

Roles further constrain domain transitions


QUESTIONS?

SELinux Policy Concepts and Overvietrj1/cse543-f07/slides/03-PolicyConcepts.pdf · SELinux Policy...

Documents

Transcript of SELinux Policy Concepts and Overvietrj1/cse543-f07/slides/03-PolicyConcepts.pdf · SELinux Policy...