Security CSE473 - Spring 2008 Professor Jaeger - - PowerPoint PPT Presentation

▶
security
SMART_READER_LITE
LIVE PREVIEW

Security CSE473 - Spring 2008 Professor Jaeger - - PowerPoint PPT Presentation

Jul 06, 2023 281 likes •584 views

Security CSE473 - Spring 2008 Professor Jaeger www.cse.psu.edu/~tjaeger/cse473-s08/ CSE473 Operating Systems - Spring 2008 - Professor Jaeger Protection Protect yourself from untrustworthy users in a common space If protection is so

slide-1
SLIDE 1

CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Security

CSE473 - Spring 2008 Professor Jaeger

www.cse.psu.edu/~tjaeger/cse473-s08/

slide-2
SLIDE 2

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Protection

  • Protect yourself from untrustworthy users in a common

space

– If protection is so good, then why do we have so many vulnerabilities/attacks?

  • UNIX vulnerabilities
  • Windows vulnerabilities

2

slide-3
SLIDE 3

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

UNIX Vulnerabilities

  • Malware can trick a UNIX system in several ways
  • Act as you

– All programs you run, run with your user id – Can do anything you can do

  • Leak/modify any of your data
  • Change your permissions

– You can change your permissions -- so can your programs – So, even if you have carefully designed your permissions

  • Malware can undo them
  • Trick setuid programs

– Trusted programs that can be run by anyone

  • Including malware

– If you can craft malicious inputs then...

  • And we haven’

t even discussed program vulnerabilities

3

slide-4
SLIDE 4

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

The Morris Worm

  • Robert Morris, a 23 year old doctoral student from Cornell

– Wrote a small (99 line) program – November 3rd, 1988 – Simply disabled the Internet

  • How it did it -- summary

– Buffer overflow on the fingerd program -- has root access – Cracks user passwords on the compromised host to try on other hosts – Used liberal system configurations of the time to identify hosts that accept logins without a password from the compromised host – Scanned local interfaces for network information – Covered its tracks (set is own process name to sh, prevented accurate cores, re-forked itself)

  • Became significant because it would re-attack an already infected system

after 7 scans

4

slide-5
SLIDE 5

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Link Vulnerabilities

  • Add new path to an inode
  • Multiple names for a single inode
  • Run

– ln -s /etc/passwd badlink – setuid_program badlink < *passwd-entry* – To overwrite /etc/passwd

  • Programs have to be aware of which files they are

using

  • open(file, O_NOFOLLOW, mode)

– Prevents open from following a link

  • Also, problems with access, then open

– File name to inode mapping causes problems

5

slide-6
SLIDE 6

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

/tmp Vulnerability

  • creat(pathname, mode)
  • O_EXCL flag

– if file already exists this is an error

  • Potential attack

– Create 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

6

slide-7
SLIDE 7

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Windows Vulnerabilities

  • And Windows has been worse
  • Many vulnerable programs

– SQL server -- leveraged by Code Red

  • Many misconfigurations

– All ISS Services were enabled by default -- Code Red again

  • Additional challenges

– Registry is a centralized store of information that is accessible to malware

  • Extensible systems

– Easy to install malware (keyloggers, spyware, bots)

  • The story has improved some in software engineering,

but we still have significant issues

7

slide-8
SLIDE 8

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Secrecy

  • Does the following protection state ensure the secrecy
  • f J’s private key in O1?

8

O1 O2 O3 J R R W R W S2 N R R W S3 N R R W

slide-9
SLIDE 9

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Integrity

  • Does the following access matrix protect the integrity of

J’s public key file O2?

9

O1 O2 O3 J R R W R W S2 N R R W S3 N R R W

slide-10
SLIDE 10

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Trusted Processes

  • Does it matter if we do not trust some of J’s processes?

10

O1 O2 O3 J R R W R W S2 N R R W S3 N R R W

slide-11
SLIDE 11

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Protection vs Security

  • Protection

– Security goals met under trusted processes – Protects against an error by a non-malicious entity

  • Security

– Security goals met under potentially malicious processes – Protects against any malicious entity

  • For J:

– Non-malicious process shouldn’t leak the private key by writing it to O3 – A potentially malicious process may contain a Trojan horse that can write the private key to O3

11

slide-12
SLIDE 12

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Reference Monitor

  • Guarantees

– Complete mediation of all security-sensitive operations – Tamperproof – Simple enough for verification of correctness

12

slide-13
SLIDE 13

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Complete Mediation

  • Ensure that OS operations that impact security are mediated

13

System System Interface Interface Entry Entry Points Points Monitor Monitor Policy Policy Access Access Hook Hook Access Access Hook Hook Access Access Hook Hook Security-sensitive Security-sensitive Operation Operation Security-sensitive Security-sensitive Operation Operation Security-sensitive Security-sensitive Operation Operation

Authorize Request? Yes/No

slide-14
SLIDE 14

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Tamperproof - Trusted Computing Base

  • Programs upon which the correct enforcement of

security depends, including...

– BIOS, Bootloader, ... – Operating system – Trusted services

  • Initialization, administration, installation, ...

– Privileged programs

  • Authentication, network facing daemons, root programs

– Programs run by administrative users

  • Could be anything

– Programs entrusted by the system for enforcement

  • Servers (mail, web, etc) -- support multiple users
  • Clients (browser, email, etc) -- control the user’s data
  • In order to verify, TCB must be manageable

14

slide-15
SLIDE 15

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Tamperproof - Mandatory Access Control

  • Discretionary Access Control

– UNIX and Windows use this – File “owners” can modify their file permissions

  • Add so can their programs
  • Mandatory Access Control

– System-defined protection state – System-defined labels of processes and file

  • Cannot be modified by users or their programs

– So, can define specific security goals – And depend on them being enforced

  • Challenge: Flexibility

15

slide-16
SLIDE 16

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Verification

  • What are the security goals of a system?

– How do we determine that they are met?

  • Showing that a program is doing the right thing is an

intractable problem in general

– And systems are extensible...

  • So, we have simple goals for complex systems

16

slide-17
SLIDE 17

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Secrecy Goal - Multilevel Security

  • A multi-level security system tags all object and subject

with security tags classifying them in terms of sensitivity/access level.

– We formulate an access control policy based on these levels – We can also add other dimensions, called categories which horizontally partition the rights space (in a way similar to that as was done by roles) security levels categories

17

slide-18
SLIDE 18

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

MLS Example

Access is allowed if

subject clearance level >= object sensitivity level and subject categories ⊇ object categories (read down) Q: What would write-up be?

Hence,

Bob: CONF., {INTEL}) Charlie: TS, {CRYPTO, NUC, INTEL}) Alice: (SEC., {CRYTPO, NUC}) DocA: (CONFIDENTIAL, {INTEL}) DocB: (SECRET, {CRYPTO}) DocC: (UNCLASSIFIED , {NUC})

18

slide-19
SLIDE 19

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Integrity Goal - Biba Integrity

  • Biba defined a dual of secrecy for integrity

– Lattice policy with

  • No read down
  • No write up

– Q: Why would this work?

  • The lattice model for secrecy matched the paper world,

does this integrity model?

  • What is a realistic view of integrity?

19

slide-20
SLIDE 20

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

UNIX/Windows are Not Reference Monitors

  • Why do current protection systems fail to meet these?

– Complete mediation

  • Do not identify and enforce all security-sensitive operations
  • Processing is not attributed correctly -- your malware runs as you

– Tamperproof

  • Can modify policy
  • Extensible systems and kernels

– Simple enough to verify

  • All programs that can perform setuid are in the TCB (all programs)
  • Policies do not ensure secrecy and integrity
  • So, they are not even close to enforcing security!

20

slide-21
SLIDE 21

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Secure Systems

  • Have any ever been built? Yes and no.

– An open and completely secure system is not possible – But, their have been a variety of attempts at providing real security in systems

  • However, these have been of limited use and

discussion

– Seminal multiprogrammed OS: Multics

  • Many of the security concepts were developed in 60’s and 70’s

– Security kernels

  • Scomp, GEMSOS, XTS-300/400, STOP, ...

– MLS systems

  • Trusted Solaris, SELinux, various other systems

– Virtualization

  • The next wave

21

slide-22
SLIDE 22

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Multics Protection Rings

22

  • Successively less-privileged “domains”
  • Example: Multics (64 rings in theory, 8 in practice)
slide-23
SLIDE 23

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Integrity Protection via Rings

  • High integrity processes and data are associated with a ring

– Lower integrity processes (in lower rings) cannot access directly – So, these processes are protected from writes

  • No direct writes from lower integrity rings
  • Invocations from lower integrity rings are trapped (think setuid)

– However, high integrity processes can read low integrity data

  • Violates Biba
  • What kinds of problems could this cause?
  • When a lower integrity ring process invokes a procedure in a

higher integrity ring – Must be authorized to access that ring

– Must pass a ‘gatekeeper’ that checks the arguments

  • When a higher integrity ring process invokes a procedure in a lower

integrity ring – Must be authorized to that ring – The process’s ring is changed while it executes that code

23

slide-24
SLIDE 24

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Is Multics a Reference Monitor?

  • Complete Mediation

– Reads and writes are mediated against MLS – Reads and writes are mediated for ring access – Procedure invocations are mediated for ring access

  • And process rings are changed accordingly
  • Tamperproofing

– Rings provide protection of procedures – MLS policy is mandatory – Ring policy is limited to that ring

  • not completely mandatory, but no untrusted code in high integrity

rings

  • Simple enough to verify

– TCB: Kernel ring and a few lower rings – MLS and Ring policy define security goals

24

slide-25
SLIDE 25

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Trusted Solaris

  • Commercially successully MLS system

– Large market share of federal systems

  • Project began in 1990

– As a separate version of the Solaris system – Still available as the Trusted Extensions for Solaris 10

  • Now integrated with the mainstream kernel
  • Key Features

– Multilevel File System

  • Files with the same name at different secrecy levels

– Multilevel Windowing System

  • Prevent cut-and-paste between secrecy levels

– Solaris Zones

  • Protection domains for MLS levels

25

slide-26
SLIDE 26

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

MAC in Linux

  • In 2001, Linus Torvalds authorized the development of

a reference monitor for Linux

– So, he didn’t have to choose a single security approach

  • Linux Security Modules framework was born

– LSM defines an interface for reference monitoring modules – Anybody could build an LSM!

  • Introduced in Linux 2.6

– Version built for FreeBSD – Underway for MAC OS X

  • SELinux (RedHat) and AppArmor (SuSE) are major

LSMs

– SELinux/MLS was evaluated in 2007

26

slide-27
SLIDE 27

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

SELinux

  • LSM + much more

27

Linux Kernel SELinux LSM SELinuxfs System Processes SELinux-aware Services SELinux Bootstrap

(1) Load Policy (2) Authenticate (3) Syscalls

slide-28
SLIDE 28

Page CSE473 Operating Systems - Spring 2008 - Professor Jaeger

Summary

  • Commercial systems have protection systems

– They define protection policies and enforce them

  • But, they are not secure

– A secure system must satisfy the reference monitor guarantees

  • Satisfying these guarantees in a flexible, extensible

system in difficult

– Complete mediation – Tamperproofing – Simple enough to verify

  • But, there are a variety of systems that aim to meet

these guarantees

28