Jan 26, 2004

OS Security

CSE 525 Course Presentation

Dhanashri Kelkar

Department of Computer Science and EngineeringOGI School of Science and Engineering

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

2

OS Security

• C. Cowan, S. Beattie, C. Wright, G. Kroah-Hartman "RaceGuard: Kernel Protection From Temporary File Race Vulnerabilities",  USENIX Security Symposium 2001

• C. Wright, C. Cowan, J. Morris, S. Smalley, and G. Kroah-Hartman. Linux security modules: General security support for the linux kernel. In Linux Security Modules: General Security Support for the Linux Kernel, USENIX Security Symposium 2002.

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

3

Introduction

• A study of computer security ‣ TOCTTOU: Time of check to time of use errors

• Race in between file existence check and file creation‣ Used in temporary file creation‣ Non-atomicity problem‣ Preemptive operating system

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

4

Temporary File Creation

• mktemp()‣ filename = generateRandomName();‣ statResult = stat(filename);‣ if(!statResult) then open(filename, O_CREAT)‣ else go to step 1

• What if there is context switch between steps 2 and 3?

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

5

Security Attack

filename = generateRandomName();

statResult = stat(filename);

if(!statResult) then open(filename, O_CREAT)

ln /etc/passwd tmpfile

• Privileged program attempts to create temp file and attacker guesses the file name

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

6

Safe Temporary File Creation

• Safe mechanism:‣ filename = generateRandomName();‣ open(filename, O_CREAT|O_EXCL)

• Used by mkstemp()

• Not commonly available and portable

• Many popular programs use mktemp()

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

7

RaceGuard

• Kernel enhancement ‣ detects attempts to exploit temporary file race

conditions‣ does this with sufficient speed and precision

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

8

Temporary File Creation

• Victim Program‣ Seeks to create temp file‣ Probes for existence of the file‣ If not found, proceeds to create it

• Attacker‣ Exploits by creating a symbolic or hard link‣ Points to a security sensitive file

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

9

RaceGuard Design

• Maintains per-process cache of temporary file races in each PCB (task_struct)

• If probe result is non-existent then cache

• If file exists and name matches cached name then race attack, abort open attempt

• If file creation is without conflicts then clear entry from cache‣ To avoid false positive event

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

10

RaceGuard Implementation

• Three groups system calls:‣ To inform that a file system entry does not exist‣ To create file system entries‣ To create and remove processes

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

11

Security Testing

• Non-deterministic vulnerability• Doctored version of mktemp library call

‣ Pause program– Give attacker more time to deploy race

‣ Print file name to be created– Instead of guessing file name, provide it by printing

• Attacked programs‣ RCS 5.7, rdist 6.1.5, sdiff GNU 2.7 shadow-

utils 19990827

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

12

Compatibility Testing

• Check whether RaceGuard breaks down existing programs without race attacks

• Programs checked‣ Mozilla web/mail client‣ RedHat Linux bootup/shutdown scripts‣ CVS checkout ‣ VMW (Virtual Machine Emulation) system

• Some tweaking performed to make it work

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

13

Performance Testing

• Microbenchmarks:

• Stat non-existent file: ‣ w/o: 4.3 µS w/: 8.8 µS Overhead: 104%

• Open non-existent file:‣ w/o: 1.5 µS w/: 1.44 µS Overhead: -4%

• Fork:‣ w/o: 161 µS w/: 183 µS Overhead: 13%

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

14

Performance Testing

• Macrobenchmarks (Khernel-stone):

Real Time User Time System Time

w/o RaceGuard 10700 8838 901

w/ RaceGuard 10742 8858 904

% Overhead 0.4% 0.2% 0.3%

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

15

Where Are We?

• RaceGuard: ‣ Particular computer security case‣ Try to avoid temporary file creation races

• LSM: Linux Security Modules‣ Generic access control mechanism

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

16

Linux Access Control Mechanism

• Discretionary access control mechanism (DAC):‣ User decides who gets access

• Mandatory access control mechanism (MAC):‣ System administrator decides who gets access

• POSIX1.e

• Many more: e.g. SELinux by NSA

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

17

Problems w/ multiple access control mechanism

• No mechanism as to which is better‣ Depends on usage

• Unable to include all available security modules inside kernel‣ Kernel upgrade is needed for every new module

• Solution: ‣ Separate loadable kernel modules‣ Load module you want to use‣ Direct access to modules through syscalls

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

18

Problems with loadable modules

• No efficient mechanism for kernel modules to access kernel data‣ Modules rely on system calls‣ Highly inefficient

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

19

Linux Security Modules Mechanism

• Access calls are handled inside kernel

• Kernel uses its default policy

• If default policy grants access, kernel “consults” loaded module‣ Special hooks provided for consulting

• Access is granted only if modules says “Go ahead”

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

20

LSM Hook Mechanism

• Global table called security_ops in kernel‣ Table divided into sub-tables‣ Each sub-table has pointers to functions that

make access decisions– Default access-granting entries filled

at kernel boot time

• Each module responsible for filling up tables‣ Module registration

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

21

Module Registration & Deregistration

• Module registration fails if another LSM module already loaded and registered

• To load new module previous module needs to be un-registered‣ Success of un-registration depends on policy

set by previous module

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

22

LSM Summary

• LSM provides generic way to implement access control mechanism

• Different access control mechanisms can reside as loadable modules

• System administrator can use appropriate modules as per need

Jan 26, 2004

Dhanashri Kelkar – OGI School of Science and Engineering

23

Details Not Covered

• Implementation details

• Data storage needs of various security policies

• Module stacking

• Performance evaluation