cmpsc443 - introduction to computer and network security … › ... › cmpsc443-s09 › slides ›...

CMPSC443 - Introduction to Computer and Network Security Page

CMPSC443 - Introduction to Computer and Network Security

Module: Operating System Security

Professor Patrick McDanielSpring 2009

1


OS Security• An secure OS should provide (at least) the

following mechanisms‣ Memory protection‣ File protection‣ General object protection‣ Access authentication

• How do we go about designing a trusted OS?• “Trust” in this context means something

different from “Secure”

2


Trust vs. Security • When you get your medication at a pharmacy, you are

“trusting” that it is appropriate for the condition you are addressing. In effect, you are arguing internally:‣ The doctor was correct in prescribing this drug‣ The FDA vetted the drug through scientific analysis and

clinical trials‣ No maniac has tampered with the bottle

• The first two are are matters “trust”, and the last is a matter of “security”

• An OS needs to perform similar due diligence to achieve “trust” and “security”

3


Access Control Lists• ACL: a list of the principals that are authorized to have

access to some object.• Eg., O2

S1 Y

S2 Y

S3 Y

• Or more correctly:

O1: S1

O2: S1, S2, S3

O3: S3

• We are going to see a lot of examples of these throughout the semester.

4


ACL in systems• ACLs are typically used to implement discretionary

access control• For example: you define the UNIX file system ACLs

using the chmod utility ….

5


Discretionary Access Control in UNIX FS

• The UNIX filesystem implements discretionary access control through file permissions set by user

• The set of objects is the files in the filesystem, ‣ e.g., /etc/passwd

• Each file an owner and group (subjects)‣ The owner is typically the creator of the file, and the entity

in control of the access control policy‣ Note: this can be overridden by the “root” user

• There is a additional subject called world, which represents everyone else

6


UNIX filesystem rights …• There are three rights in the UNIX filesystem‣ READ - allows the subject (process) to read the contents

of the file.‣ WRITE - allows the subject (process) to alter the contents

of the file.‣ EXECUTE - allows the subject (process) to execute the

contents of the file (e.g., shell program, executable, …)

• Q: why is execute a right?• Q: does the right to read a program implicitly give you

7


The UNIX FS access policy• Really, this is a bit string encoding an access matrix• E.g.,

rwx rwx rwx

• And a policy is encoded as “r”, “w”, “x” if enabled, and “-” if not, e.g,

rwxrw--x• Says user can read, write and execute, group can read

and write, and world can execute only.

WorldGroupOwner

8


Caveats: UNIX Filesystem• Access is often not really this easy: you need to have

certain rights to parent directories to access a file (execute, for example)‣ The reasons for this are quite esoteric

• The preceding policy may appear to be contradictory‣ A member of the group does not have execute rights, but

members of the world do, so …‣ A user appears to be both allowed and prohibited from

executing access

‣ Not really: these policies are monotonic … the absence of a right does not mean they should not get access at all, just that that particular identity (e.g., group member, world) should not be given that right.

9


Window Vista Integrity• Integrity protection for writing• Defines a series of protection level of increasing

protection‣ untrusted (lowest)‣ low (Internet)‣ medium (user)‣ high (admin)‣ system ‣ installer (highest)

• Semantics: If subject’s (process’s) integrity level dominates the object’s integrity level, then the write is allowed

10


Vista Integrity• Does Vista Integrity protect the integrity of J’s public

key file O2?

O1 O2 O3

J R RW RW

S2 N R RW

S3 N R RW

11


UID Transition: Setuid• A special bit in the mode bits• Execute file ‣ Resulting process has the effective (and fs) UID/GID of file

owner

• Enables a user to escalate privilege‣ For executing a trusted service

• Downside: User defines execution environment ‣ e.g., Environment variables, input arguments, open

descriptors, etc.

• Service must protect itself or user can gain root access

• All UNIX services involves root processes -- many via setuid12


/tmp Vulnerability• creat(pathname, mode)• O_EXCL flag‣ if file already exists this is an error

• Potential attack ‣ Attacker creates file in shared space (/tmp)‣ Give it a filename used by a higher authority service‣ Make sure that service has permission to the file‣ If creat is used without O_EXCL, then can share the file

with the higher authority process

13


Other Vulnerabilities• Objects w/o sufficient control‣ Windows registry, network

• Libraries‣ Load order permits malware defined libraries

• Executables are everywhere‣ Web content, Email, Documents (Word)

• Labeling is wrong‣ Mount a new file system; device

• Malware can modify your permissions‣ Inherent to discretionary model

14


Sandboxing• An execution environment for programs that contains a

limited set of rights‣ A subset of your permissions (meet secrecy and integrity goals)

‣ Cannot be changed by the running program (mandatory)

15


UNIX Chroot• Create a domain in which a process is confined‣ Process can only read/write within file system subtree‣ Applies to all descendant processes‣ Can carry file descriptors in ‘chroot jail’

16


Chroot Vulnerability• Unfortunately, chroot can trick its own system‣ define a passwd file at <newroot>/etc/passwd‣ run su

• su thinks that this is the real passwd file

‣ gives root access• Use mknod to create device file to access physical memory

• Setup requires great care‣ Never run chroot process as root‣ Must not be able to get root privileges‣ No control by chrooted process (user) of contents in jail‣ Be careful about descriptors, open sockets, IPC that may be

available

17


Process-specific Permissions• Design the permissions of a process specific to its use

• How do we change the permissions of a process in an ACL system?

18


Confused Deputy Problem• Imagine a multi-client server‣ Clients have a different set of objects that they can access

• In an ACL system, the server always has access to all the objects‣ What happens if a client tricks the server into accessing

into another client’s objects?‣ Shouldn’t the server only have access to that client’s

objects for its requests?

19


Capabilities• A capability is the tuple (object, rights)• A capability system implements access control by

checking if the process has an appropriate capability‣ Simple, right?‣ This is a little like a ticket in the Kerberos system

• Q: Does this eliminate the need for authentication?20


Capabilities • A: Well, yes and no …• Capabilities remove the overhead of managing per

object rights, but add the overhead of managing capabilities

• Moreover, to get any real security, they have to be unforgeable‣ Hardware tags (to protect capabilities)‣ Protected address space/registers‣ Language based techniques

• Enforce access restrictions on caps.

‣ Cryptography • Make them unforgeable

21


Real OS Capabilities

• The OS kernel manages capabilities in the process table, out of reach of the process

• Capabilities added by user requests (that comply with policy)

Process Table

.

.

.

Process ZX CR DW E

.

.

.

C ListA

B

C

D

RX RW

22


User space capability?• Well, what are the requirements?‣ Authenticity/integrity - do not want malicious process to

forge capabilities• Start with the data itself: [object, rights]‣ Object is typically encoded with identifier, or by some other

tag (capabilities are sometimes known as tags)‣ Rights are often fixed (read, modify, write, execute, etc.)

• Now, do what you with any other data (assume the kernel has a secret key k)

E(k, [Oi, r1, r2, … rn])

• What’s wrong with this construction (I got it from the website of one of the experts in the area)?

23


The right construction• Encryption does not provide authenticity/integrity, it

provides confidentiality

[Oi, r1, r2, … rn],HMAC(k, [Oi, r1, r2, … rn])

• So how would you attack the preceding construction?

24


A (fictional) Capability Example• We use the “ls -lt” command to view the contents of our home

directory in a OS implementing capabilities:‣ Initially, our shell process has RWX capabilities for our home directory, and

RX capabilities for all the directories to the root.‣ The “ls -lt” command is exec()ed, and the shell delegates the directory

permissions by giving “ls” the capabilities • Note that the capabilities are _not_ tied to any subject

‣ The “ls -lt” process exercises the rights to read the directories structure all the way down to the local

‣ Of course, the “ls -lt” process now need to obtain read rights to the files (to get their specific meta-information), and obtains them by appealing to the security manager (in kernel) -- the request fulfills the policy, and they are added and exercised

‣ The “ls -lt” uses access rights given to the terminal to write output

• Note: there are many ways that the policy can be implemented, rights handed off, etc. We will talk about a couple in the following discussions.

25


MAC Systems

• Major Effort: Multics‣ Multiprocessing system -- developed many OS concepts

• Including security

‣ Written in PL/1‣ Begun in 1965

• Development continued into the mid-70s

‣ Used until 2000‣ Initial partners: MIT, Bell Labs, GE/Honeywell‣ Other innovations: hierarchical filesystems, dynamic linking

• Subsequent proprietary system, SCOMP, became the basis for secure operating systems design

26


Multics Goals• Secrecy‣ Multilevel security

• Integrity ‣ Rings of protection

• Reference Monitoring‣ Mediate segment access, ring

crossing

• Resulting system is considered a high point in secure system design

27


Multics Basics• Processes are programs that are executing within

Multics (seems obvious now ...)‣ Protection domain is a list of segments‣ Stored in the process descriptor segment

• Segments are stored value regions that are accessible by processes, e.g., memory regions, secondary storage‣ Segments can be organized into hierarchies ‣ Local segments (memory addresses) are accessed directly‣ Non-local segments are addressed by hierarchy

• /tape/drive1/top10k

• /etc/conf/http.conf

• This is the genesis of the modern hierarchical filesystem!

28


Segment Management• PDS acts like segment working

set for process‣ Segments are addressed by

name (path)‣ If authorized, added to PDS‣ Multics security is defined

with respect to segments

• The supervisor (kernel) makes decisions and adds to PDS‣ supervisor is isolated by

protection rings29

Segment Descr. Word 0

Segment Descr. Word 1

....

Segment Descr. Word N

Segment 0

Segment 1

Segment N

Process Descriptor Segment


Protection Rings• Successively less-privileged “domains”• Modern CPUs support 4 rings‣ Use 2 mainly: Kernel and user

• Intel x86 rings‣ Ring 0 has kernel

‣ Ring 3 has application code

• Example: Multics (64 rings in theory, 8 in practice)30


What Are Protection Rings?• Coarse-grained, Hardware Protection Mechanism• Boundary between Levels of Authority‣ Most privileged -- ring 0‣ Monotonically less privileged above

• Fundamental Purpose‣ Protect system integrity

• Protect kernel from services

• Protect services from apps

• So on...

31


Intel Protection Ring Rules• Each Memory Segment has a privilege level (ring

number)

• The CPU has a Current Protection Level (CPL)‣ Level of the segment where instructions are being read

• Program can read/write in segments of higher level than CPL‣ kernel can read/write user space

‣ user cannot read/write kernel• why not?

32


Ring 0

Ring 3

Protection Ring Rules• Program cannot call code of

higher privilege directly‣ Gate is a special memory

address where lower-privilege code can call higher• Enables OS to control where

applications call it (system calls)

33

Gate

No gate


Multics Interpretation• Kernel resides in ring 0• Process runs in a ring r‣ Access based on current ring

• Process accesses data (segment)‣ Each data segment has an access

bracket: (a1, a2)• a1 <= a2

‣ Describes read and write access to segment• r is the current ring• r <= a1: access permitted• a1 < r <= a2: r and x permitted; w denied• a2 < r: all access denied

34

1

2

3

4

5

6

7

0

a1

a2

RWX

R-X

---

Ring


Multics Interpretation (con’t)• Also different procedure segments

‣ with call brackets: (c1, c2), c1 <= c2

‣ and access brackets (a1, a2)

‣ The following must be true (a2 == c1)

‣ Rights to execute code in a new procedure segment• r < a1: access permitted with ring-crossing fault

• a1 <= r <= a2 = c1: access permitted and no fault

• a2 < r <= c2: access permitted through a valid gate

• c2 < r: access denied

• What’s it mean?‣ case 1: ring-crossing fault changes procedure’s ring

• increases from r to a1

‣ case 2: keep same ring number

‣ case 3: gate checks args, decreases ring number

• Target code segment defines the new ring

35

1

2

3

4

5

6

7

0

a1

a2

Allow

with

gate

No ring

fault

Denied

Ring

c2

c1

Ring

fault


Examples• Process in ring 3 accesses data segment‣ access bracket: (2, 4)‣ What operations can be performed?

• Process in ring 5 accesses same data segment‣ What operations can be performed?

• Process in ring 5 accesses procedure segment‣ access bracket (2, 4) ‣ call bracket (4, 6)‣ Can call be made?‣ How do we determine the new ring?‣ Can new procedure segment access the data segment

above?36


Multics Vulnerability Analysis• Detailed security analysis covering‣ Hardware‣ Software‣ Procedural features (administration)

• Good news‣ Design for security‣ System language prevents buffer overflows

• Defined buffer sizes

‣ Hardware features prevent buffer overflows • Addressing off segment is an error

• Stack grows up

‣ System is much smaller than current UNIX systems37


Vulnerabilities Found• Hardware

‣ Indirect addressing -- incomplete mediation• Check direct, but not indirect address

‣ Mistaken modification introduced the error

• Software‣ Ring protection (done in software)

• Argument validation was flawed

• Certain type of pointer was handled incorrectly

‣ Master mode transfer• For performance, run master mode program (signaler) in user ring

• Development assumed trusted input to signaler -- bad combo

• Procedural‣ Trap door insertion goes undetected

38


Question• If Multics was so good why was it so insecure?• If multics was so good, why didn’t anybody use it?

39


Midterm • Next Thursday (3/5/09) - in class• Exam will test three kinds of things:‣ knowledge (do you know termonology/approaches)‣ synthesis (can you extrapolate or compare concepts)‣ application (can you apply what you learned)

• Structure:‣ 14 - 3 point short answer questions (42 points)‣ 4 - 7 point long answer questions (28 points)‣ 3 - 10 point problem questions (30 points)

40


Sample Questions• Short answer question: Why are active attacks easier to detect than

passive attacks?

• Long answer question: Explain what resource imbalances are and why managing them is so important to protecting a network?

• Problem question: Acme archival storage systems is a company that promises to securely store customer data. They provide a online system that the customer submits documents for storage which Acme encrypts using AES and a key specific to each request. Acme only accepts requests from 8am to 5pm, Monday through Friday, and they are open on all holidays not falling on a weekend. For the purposes of this exercise, you can assume that Acme has been in operation for exactly 700 days. A customer document di is encrypted as E(di , kr ), where the key kr is computed the kr = h(ti) and ti is the timestamp (with millisecond granularity) of the request submission. What is the entropy of the key?

41