linux vs. selinuxsecuresw.dankook.ac.kr/iss19-2/2019_os_se_13_linux_n_selinux.pdf ·...

Operating System Security

Fall, 2019

Cho, Seong-je (조성제)

sjcho at dankook.ac.kr

Computer Security & OS Lab

Security-Enhanced Linux

Linux vs. SELinux

Contents

Linux : DAC

SELinux : DAC + RBAC + TE + (MLS)

Summary

Source & References● Introduction to SELinux (https://web.mit.edu/rhel-doc/5/RHEL-5-

manual/Deployment_Guide-en-US/ch-selinux.html)

● Secure Operating System Example: SELinux

● Security-Enhanced Linux (https://www.nsa.gov/What-We-Do/Research/SELinux/ )

● Computer Security: Principles and Practice, Chapter 23 – Linux Security

● Securing Linux, Hyungjoon Koo and Anke Li, Stony Brook University, 2004

● Mandatoray Access Control in Linux, CMPSC 443 – Spring 2012, Professor Jaeger.

2Computer security & OS lab, DKU

https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-selinux.html

https://www.nsa.gov/What-We-Do/Research/SELinux/

Access Control

DAC

Access Control Lists (ACLs)

Minimal ACLs, Extended ACLs

-3-Computer security & OS lab, DKU

DAC: Group and Object attributes


User

User

User

UserGroup

Attribute

Object

Object

Object

PermissionAssignment

User Group Has Access To Objects With the Attribute

• Traditional ACL

• Attribute = Name + Permissions + Size + Time date + Location + …

DAC

Standard Linux passwd Security


Source: SELInux Policy Concepts and Overview, Tresys Technology

DAC




MAC in SELinux

$ id –Z

$ ls –Z

$ ps -Z

-8-Computer security & OS lab, Dankook University

allow user_t passwd_exec_t : file {read getattr execute };type_transition user_t passwd_exec_t : process passwd_t;allow user_t passwd_t : process { transition noatsecure siqinh rlimitinh };

LSM: Linux Security Module

LSM & Reference Monitor


What is SELinux?

Security-Enhanced Linux (SELinux) is a security architecture integrated into the 2.6.x kernel using the Linux Security Modules (LSM).

● It is a project of the US NSA and the SELinux community.

● SELinux integration into Red Hat Enterprise Linux was a joint effort between the NSA and Red Hat.

● Two popular LSMs: AppArmor and SELinux

SELinux provides a flexible MAC system built into the Linux kernel.

● Under standard Linux DAC, an application or process running as a user (UID or SUID) has the user's permissions to objects such as files, sockets, and other processes.

● Running a MAC kernel protects the system from malicious or flawed applications that can damage or destroy the system.


Brief history

Increasing the demand for reference monitor in Linux ● A mechanism to enforce access control

● Originate from orange book from the NSA: too generic

− NSA: National Security Agency in US

Adopting LSM in Linux Kernel ● Originally a set of kernel modules in 2.2, updated in 2.4

● LSM (Linux Security Module) Feature in 2.6

− SELinux developed by the NSA and released in 2001

− Default choice for Fedora/RedHat Linux

Lots of early works ● Subdomain (AppArmor), Flask (SELinux), OpenWall, …

− SELinux originally started as the Flux Advanced Security Kernel (FLASK) development by the Utah university Flux team and the US Department of Defense.


Reference Monitor

Reference Monitor● An authorization system that determines whether a subject is allowed to

perform an operation on an object

− Takes as input a request

− Returns a binary response indicating whether the request is authorized or not

LSM● Implementation of a reference monitor

● Requirements

− Modularized security

− Loadable modules

− Centralized MAC

− LSM API



Source: Operating system security, Jaeger’08, Morgan & Claypool

How does LSM work?

Predefined LSM hooks were placed in Linux kernels● The hooks are interfaces to the reference monitor

● Hook placement is non-trivial

● Over 150 hooks

How to invoke permission check? ● By calling the initiated function pointers in security_ops

● Aka LSM hooks

One hook is shown below:


static inline int security_inode_create (struct inode *dir,

struct dentry *dentry, int mode)

{

if (unlikely (IS_PRIVATE (dir)))

return 0;

return security_ops->inode_create (dir, dentry, mode);

}

LSM design - Hooking

Simple diagram of hooking



LSM design – Hooking example

open() hook process

Process syscall in user

• file path

• operation

Invoke syscall in kernel

Lookup inode

Check DAC

Hook & check MAC

Grant access

MPS & MAC

Mandatory protection system (MPS):● Subjects and objects represented by labels

● Protection state: the operations that subject labels may perform on object labels

● Labeling state: mapping objects to labels

● Transition state: defines what relabeling is allowed

In a MPS● The set of labels are defined by trusted administrators

● The set of labels are immutable

● Protection state, labeling state, and transition state can only be modified by trusted administrators through trusted programs

● This is called Mandatory Access Control (MAC)


Secure OS

Secure Operating System● A system with a reference monitor access enforcement mechanism that

satisfies the requirements below when it enforces a mandatory protection system (MPS).

− Complete Mediation: all security-sensitive ops

• All accesses to all objects have to go through the reference monitor

− Tamperproof: untrusted processes cannot modify access enforcement system

− Verifiable: small TCB (Trusted Computing Base)


Security-Enhanced Linux

SELinux


SELinux

SELinux: A MAC security model using LSM● Provides fine-grained access control policy

● Policy writers define the policy – a non-trivial job

● Quality of protection depends largely on the policy specification

SELinux can enforce mandatory access controls (MAC).

Type Enforcement (TE)● Implements Domain Type Enforcement.

● Labeling subjects and objects: Domains for processes and Types for files and other objects

● Rules enforce how domains can access types.


SELinux = LSM + much more

The pseudo file system selinuxfs is mounted at /selinux/.

● It provides the SELinux policy API for userspace. Some of what libselinux abstracts from this pseudo file system is loading policy, enabling or disabling SELinux, etc.


Step 1: Convert call to LSM hooks to authorization queries

Parameters to an LSM call

● Subject: the current process that is making the call

● Object: inode

● Operations requested

− Operations: rwx, append, create, rename, (un)link, (un)lock, …

Convert subject and object to labels

● Called “context” in SELinux

● Stored in kernel

● Each object also has a “data type”


Step2: Retrieve SELinux Policy Entry for the access request

Example policy statement:


allow <subject_type> <object_type>:<object_class> <operation_set>

allow user_t passwd_exec_t:file executeallow passwd_t shadow_t:file {read write}

SELinux

Access rules:

● Syntax: (allow | auditallow | dontaudit) src_typetarget_type:classes permissions;

● Example: allow sshd_t shell_exec_t:file execute;

● Meaning: when a subject of sshd_t accesses an object of shell_exec_t, it has the execute permissions if the object is the file class.

Rules for the type of a new object:

● Example: type_transition sshd_t tmp_t:devfile_class_set

cardmsg_dev_t;

● Meaning: When sshd daemon creates a device file in the tmp directory, the new file is labeled with cardmsg_dev_t.


SELinux

Key concepts:● Domains: Classification of a subject.

● Types: Classification of an object (really the same thing as a domain but applied to objects).

● Users: Identifier for a single user or an equivalence class of users.

● Class: Type of an object, e.g., file or process.

− File, IPC, network, object, …

SELinux Policy Rules express an MPS ● Protection state – every subject, object, operation

● Labeling state – every file and process

● Transition state – every process and file transition on access

All policy rules are defined explicitly● Lots of rules are necessary for a standard Linux distribution


SELinux Protection State

All the policy statements constitute the protection state of SELinux

● Can be large and complicated

− More than 1000 labels defined in the reference policy

− Tens of thousands of allow statements

● More flexible than standard Unix access control

− Allows restriction of access not possible or cumbersome under Unix

The permissions in an SELinux system are produced by a runtime analysis

● Step 1: Run programs

− In a controlled (no attacker) environment

− No enforcement is on

● Step 2: Audit all permissions used

● Step 3: Generate policy file

− Give the subject label associated with that program

− All the permissions in the audit file


SELinux Labeling State

Map users/systems resources to labels

Files and users known to the system at boot-time must be associated with their MAC policy labels

● Map file paths to labels (regular expressions)

● Map users to labels (by name)

− These labels are assigned to their initial processes

Labeling state defines how newly created processes and resources are labeled

– File context specification: define mapping from file paths to object context

– e.g.,

<file path expr> <context>

/etc/shadow.* system_u:object_r:shadow_t:s0

/etc/*.* system_u:object_r:etc_t:s0


SELinux Transition State

Run the privileged passwd program

Simplified view -- takes several policy rules to do this



Defines under what conditions labels of subjects/objects may change● e.g., user label transition


type_transition <current_type> <executable_file_type>:process <resultant_type>

type_transition user_t passwd_exec_t:process passwd_t

A process with user_t label will change to passwd_twhen executing a file with passwd_exec_t label

All the transition must be authorized● i.e., there must be corresponding “allow” statements for the transition


Defines under what conditions labels of subjects/objects may change● e.g., file label transition


type_transition <creator_type> <default_type>:<class> <resultant_type>

type_transition passwd_t etc_t:file shadow_t

A process with passwd_t label creates a file that would have etc_t, but with this policy the file will have the shadow_t label

Security Contexts

each individual subject & object in SELinux is governed by a security context

Security context consists of three security attriburtes● user - individual human/daemon, or user identity (SID, Security identifier)

− SELinux maintains its own list of users

− user labels on subjects specify account's privileges

− user labels on objects specify its owner

− SELinux user account associated with a subject or object

− Different from traditional UNIX account (i.e /etc/passwd)

● role - like a group, assumed by users− Postfix _r (i.e sysadm_r, user_r, object_r, …)

− a user may only assume one role at a time,

− may only switch roles if and when authorized to do so

− Associate the role with domains (types) that it can access

● domain (type) - a sandbox being a combination of subjects and objects that may interact with each other− Postfix _t (i.e user_t, passwd_t, shadow_t, …)

− Typically type is assigned to an object, and domain to a process


Security Context in SELinux

A combination of user, role and type● Who is the user?

● What is their role?

● What can they do?

Example$ ls -l ssh.ps

-rw-r----- 1 rcotter rcotter 67014 Feb 10 14:16 ssh.ps

$ ls -Z ssh.ps

-rw-r----- rcotter rcotter user_u:object_r:user_home_t ssh.ps

SELinux assigns subject and objects a security context

Security context is only access control attribute in SELinx

Security Identifier (SID): number represents security context active within the kernel


Standard Linux vs SELinux

More on Security Contexts● Linux and SELinux access controls are orthogonal

− each mechanism uses its own access control attributes

− two separate access checks; both must pass

☞Linux UIDs and SELinux UID are independent

● A process type is also called a “domain”

− though object and subject contexts are identical

● Type is most used part of a context (by far) in policies

− emphasis on type enforcement in a policy


Decision making with policy

Access decision ● Based on security context

● allow, auditallow, dontaudit, and neverallow

Q: how can we decide policy for a temporary object? ● temp processes (i.e fork) and files

A: transition decision ● Process creation: domain transmission

● File creation: type transmission (labelling)


type_transition <curr_type> <exe_file_type>:process <res_type>

type_transition user_t passwd_exec_t:process passwd_t

Transition decision examples

Process creation● Domain decision


Source: https://flylib.com/books/en/2.813.1.22/1/ (Transition decisions)

File creation● Type decision

https://flylib.com/books/en/2.813.1.22/1/

Security Context Example

Password Change in SELinux


Security context example

Alice wants to change her password ● SID Alice with the user role, user_r

● Role permitted to run typical user processes

● Any process with user_t to execute the passwd_exec_t label


For changing Password

For user to run passwd program

● Only passwd should have permission to modify /etc/shadow

Need permission to execute the passwd program

● allow user_t passwd_exec_t:file execute (user can exec passwd)

● allow passwd_t passwd_exec_t:file entrypoint

Must transition to passwd_t from user_t

● allow user_t passwd_t:process transition (can run with passwd perms)

● type_transition user_t passwd_exec_t:process passwd_t

Passwd can the perform the operation

● allow passwd_t shadow_t:file {read write} (can edit shadow file)


Passwd Program Example



Contexts & Rules for Password Change in SELinux

-r-s--x--x root root system_u:object_r:passwd_exec_t /usr/bin/passwd

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

joe’s shell domain : user_t

Password program’s domain type : passwd_t


● passwd process domain type (passwd_t) can access the shadow password file

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

● Rules for Domain transitions

allow user_t passwd_exec_t:file { getattr execute };

allow passwd_t passwd_exec_t:file entrypoint;// This provides entrypoint access to the passwd_t domain.

// What the entrypoint permission does is define which executable files may “enter” a domain.

allow user_t passwd_t:process transition;

● Rule for Default domain transitions

type_transition user_t passwd_exec_t:process passwd_t;// On an execve() system call, if the calling process’ domain type is user_t and the executable file’s type is

passwd_exec_t, a domain transition to a new domain type (passwd_t) will be attempted

Domain: user_t, passwd_t

File: shadow_t, passwd_exec_t




$ ls –Z /usr/bin/passwd /etc/shadow

-r-s--x--x root root system_u:object_r:passwd_exec_t /usr/bin/passwd

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




Problem of Domain Transitions

SELinux Domain Transitions



Domain trans. requires access

● The “execute permission” to executable file must be for the original domain

● Original domain permission to transition to new domain

● New domain permission to be entered via program




1) Lets user_t execute an execve() system call on passwd_exec_t

allow passwd_t passwd_exec_t : file entrypoint;2) This rule provides entrypoint access to the passwd_t

domain. What the entrypoint permission does is define which executable files may “enter” a domain.

allow user_t passwd_t : process transition;3) The original type (user_t) must have transition

permission to the new type (passwd_t) for the domain transition to be allowed.

Domain transition

allow user_t passwd_exec_t : file {getattr execute};

allow passwd_t passwd_exec_t : file entrypoint;

allow user_t passwd_t : process transition;

Assuming that only the passwd executable file is labeled with passwd_exec_t, and that only type passwd_t has entrypoint permission to passwd_exec_t, we have the situation that only the password program can run in the passwd_t domain type.

For a domain transition to succeed, all three rules are necessary. Therefore, a domain transition is allowed only when the following three conditions are true:

1. The process' new domain type has entry-point access to an executable file type.

2. The process' current domain type has execute access to the entry point file type.

3. The process' current domain type has transition access to the new domain type.

The execve() system call is the only way to change a domain type,





• A type_transition rule causes a domain transition to be attempted by default, but it does not allow it, that's why the other 3 rules had to be created

Type Transition Statement in SELinux



Default domain transition: type_transition Statement

● The type_transition rule indicates that by default on an execve() system call, if the calling process' domain type is user_t and the executable file's type is passwd_exec_t, a domain transition to a new domain type (passwd_t) will be attempted

● Causes a domain type transition to be attempted on execve()

Policy Implementation

Policy sources ● .te files (type enforcement)

− Define rules and macros(m4) & assign permissions

● .fc files (file context)

− Define file contexts, supporting regular expression

● RBAC files

● User declarations

Makefile (target: policy, install, …)

Policy compiler ● Merge all policies to policy.conf

● Generate policy binary, centralized policy storage


SELinux Policy Management

creating and maintaining SELinux policies is complicated and time-consuming

a single SELinux policy may consist of hundreds of lines of text

● SELinux policies take the form of various, lengthy text files in /etc/security/selinux.

RHEL (Red Hat Enterprise Linux) has a default “targeted” policy

● defines types for selected network apps

● allows everything else to use DAC controlsProcesses that are targeted (system processes) run in a confined domain (initrc_t), and

processes that are not targeted (logged-in users) run in an unconfined domain (unconfined_t).

RHEL’s system-config-securitylevel GUI to configure the targeted policy● system-config-securitylevel is a graphical program for configuring firewall and SELinux

settings.

have a range of SELinux commands

● chcon, checkpolicy, getenforce, newrole, run_init, setenforce, and setfiles


SELinux commands

chcon: change security context

checkpolicy: checks and compiles a SELinux security policy configuration into a binary representation that can be loaded into the kernel

getenforce : get the current mode (enforcing/permissive/disable) of SELinux

newrole : run a shell with a new role

run_init : run an init script in the proper context/etc/selinux/POLICYTYPE/contexts/initrc_context - contains the context to run init scripts under

setenforce : modify the mode (enforcing==1/permissive==0) SELinux is running in./etc/grub.conf, /etc/selinux/config

setfiles : set file security contexts.

sestatus : status tool which is used to get the status of a system running SELinux/etc/sestatus.conf

load_policy : load a new policy into the kernel


Linux Kernel Security

SELinux, AppArmor, Smack, TOMOYO, grsecurity, IIDEF, …


Feature SELinux AppArmor Grsecurity Smack

MAC O O O O

MLS O O ? O

RBAC O O O O

Feature Security label Profile ACLs Label

Vender support RedHat Novell X ?

Recommend OSRedHat,

Debian,CentOSUbuntu,

Suse, OpenSuseAny Linux

distributionMeegoTizen

Summary

• SELinux: a comprehensive Linux Security Module– Aim is to provide a secure OS foundation to commercial systems

• Goal: tamperproofing of system’s trusted computing base– However, strong integrity guarantees are difficult in a commercial system

– Aim for least privilege

• Key task is the design of the SELinux policy – Complete, but complex (“assembly language of security”)

☞ SELinux Security– Complete Mediation

• Depends on LSM hook placement

– Tamperproof• Policy protects kernel from “weak accesses”

– Verifiable

Computer Security & OS Lab., DKU - 54 -

SELinux Security Models

Type Enforcement (TE)● Confine processes (subjects) to domains by using security contexts.

Role-based Access Control (RBAC)● Recognizes that users often need to move from one domain to another.

RBAC rules explicitly allow roles to move from one domain to another

Multi-Level Security● Enforce Bell-LaPadula model.

● Users allowed to read at one level cannot read at higher levels.

● Also users allowed to write at 1 level are not allowed to write at a lower level.− Ensures that secure information does not propagate to lower levels.


SELinux Commands

# sestatus

SELinux status: enabled

SELinuxfs mount: /selinux

Current mode: enforcing

Mode from config file: enforcing

Policy version: 24

Policy from config file: targeted

# setenforce 0

# sestatus



Current mode: permissive


Policy version: 24



# sestatus



Current mode: enforcing


Policy version: 24


# setenforce 0

# sestatus



Current mode: permissive


Policy version: 24


SELinux vs AppArmor

Whole system vs. only a set of applications

Types & domains vs. defining permission directly

Strict MAC implementation vs. Partially implement

Extended attributes vs. pathname

Difficulty to configure ● SELinux needs 4x bigger conf. file than AppArmor

Overhead? ● 7% vs. 2%

SELinux and AppArmor can both greatly enhance OS security.

Choice depends on what you need.


linux vs. selinuxsecuresw.dankook.ac.kr/iss19-2/2019_os_se_13_linux_n_selinux.pdf ·...

Documents