1 / 22

Security

Security. Andrew Whitaker CSE451. Motivation: Internet Worms.

rayya
Download Presentation

Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Andrew Whitaker CSE451

  2. Motivation: Internet Worms “On July 19th, 2001, a self-propagating program, orworm, was released into the Internet. The worm, dubbed Code-Red v2, probed random Internet hosts for a documented vulnerability in the popular Microsoft IIS Web server. As susceptible hosts were infected with the worm, they too attempted to subvert other hosts, dramatically increasing the incidence of the infection. Over fourteen hours, the worm infected almost 360,000 hosts, reaching an incidence of 2,000 hosts per minute before peaking [1]. The direct costs of recovering from this epidemic (including subsequent strains of Code-Red) have been estimated in excess of $2.6 billion [2]” Source: Internet Quarantine: Requirements for Self-Propagating Code David Moore, Colleen Shannon, Geoffrey M. Voelker, Stefan Savage

  3. Motivation • What’s happening here?

  4. Why Has Security Gotten So Bad? • The Internet • Extensibility • Complexity • An enormous trusted computing base • Grandma

  5. Outline • Protection • Defining what is allowed • Security • Enforcing a protection policy • In the face of adversaries

  6. Protection systems • Protection: controlling who gets access to what • Key concepts: • Objects (the “what”) • Principles (the “who”, user or program) • Actions: (the “how”, or operations) • Goal: separate mechanism from policy • OS only provides protection mechanisms • Somebody else chooses the protection policy

  7. Representing Protection • Protection can be modeled with a matrix • Two implementation strategies • Access control lists (rights stored with objects) • Capabilities (rights stored with principals) objects principals capability ACL

  8. More on UNIX-style protection • Not a full access-control list • Can only specify owner, group, world permissions • “Objects” are files • Can specify read, write, execute permissions • Owner has the power to change access control • This is called discretionary access control • All programs run as a particular user • The user must have “execute” privilege • There is an all-powerful root user

  9. Protection Implementation struct cse451_inode { __u16 i_mode; __u16 i_nlinks; __u16 i_uid; __u16 i_gid; time_t i_atime; time_t i_mtime; time_t i_ctime; __u32 i_filesize; __u32 i_datablocks[CSE451_NUMDATAPTRS]; };

  10. ls -al drwxr-xr-x 4 andrew tech_cs 4096 2006-12-04 17:27 proj4 drwxr--r-- 4 andrew tech_cs 4096 2006-05-15 08:04 projFS -rw-r--r-- 1 andrew tech_cs 26648 2008-01-10 17:25 projFS.tar.bz2 drwxr-xr-x 7 andrew tech_cs 4096 2006-10-09 18:10 src drwx------ 2 andrew tech_cs 4096 2006-10-08 11:42 .ssh -rw-r--r-- 1 andrew tech_cs 275 2008-01-10 18:25 test.sh drwxr-xr-x 5 andrew tech_cs 4096 2006-10-16 13:46 trash -rw-r--r-- 1 andrew tech_cs 14 2008-02-05 17:09 urls drwxr-xr-x 3 andrew tech_cs 4096 2008-02-23 21:45 vmtrace-1.01 -rw-r--r-- 1 andrew tech_cs 99419 2008-02-12 17:01 vmtrace-1.01.tar.gz -rw------- 1 andrew tech_cs 426 2006-12-08 16:01 .Xauthority user group

  11. UNIX Users more /etc/passwd kansu:x:16151:150:Kansu Dincer:/homes/iws/kansu:/bin/csh jessefis:x:16152:153:Jesse Fischer:/homes/iws/jessefis:/bin/csh sky:x:16163:150:Skyler Magnuson:/homes/iws/sky:/bin/csh davidjsh:x:16179:150:David St. Hilaire:/homes/iws/davidjsh:/bin/csh rctucker:x:16182:150:Ryan Tucker:/homes/iws/rctucker:/bin/csh tvolpe:x:16184:153:Tripurari Volpe:/homes/iws/tvolpe:/bin/csh wolfeb:x:16186:153:Brian Wolfe:/homes/iws/wolfeb:/bin/bash yonderin:x:16309:153:Jonathan Andes:/homes/iws/yonderin:/bin/csh gu13:x:16313:150:Nicholas Brekhus:/homes/iws/gu13:/bin/bash ac360:x:16317:150:Angda Chen:/homes/iws/ac360:/bin/csh jae6:x:16322:150:Jill Edwards:/homes/iws/jae6:/bin/csh uid gid

  12. Processes and Protection • Each process has three user IDs: • Real: the user who invoked the process • Effective: the user for access control • Saved: a previous user ID • Setuid changes the effective user • Which is the one that matters for security • Two ways to invoke • setuid() system call • setuid bit • Changes the effective user to the file owner

  13. Setuid Root • Many programs run as “setuid root” • Can be invoked by anybody • But, run as root • Example: passwd • Passwords stored in a file • Users do not have access to this file • But, they need the ability to change a password • setuid root is extremely dangerous • A compromised setuid program can basically do anything

  14. Principle of Least Privilege • Each program should be given the minimum privilege to accomplish its task • setuid root is a flagrant violation of this • Least privilege for passwd: read and write the password file • Privilege afforded by root: modify any file in the system; inspect kernel memory; access any I/O device; etc.

  15. Why Can’t We Enforce Least Privilege? • The mechanisms are not sufficient • Strongly tied to the “user” concept • No restrictions on network accesses • The policy is too complex • Which files can a web browser access? • Which files can a web server access? • In the end, usability wins out over security

  16. Security in the Post-desktop World • The Web browser must provide protection Internet Flash, AJAX, Java applets, Malicious web pages, phishing attacks… Firefox Linux Hardware

  17. Research: System Call Policies • Observation: UNIX file access control is not sufficient • Approach: Add a policy language for inspecting system calls • In principle, this allows us to completely quarantine an application

  18. Example System Call Policy Language Policy: /usr/sbin/named, Emulation: native native-sysctl: permit native-accept: permit native-bind: sockaddr match "inet-*:53" then permit native-break: permit native-chdir: filename eq "/" then permit native-chdir: filename eq "/namedb" then permit native-chroot: filename eq "/var/named" then permit native-close: permit native-connect: sockaddr eq "/dev/log" then permit Source: Improving Host Security with System Call Policies Niels Provos Open question: where do the policies come from?

  19. Other Security Principles • Least Privilege • Keep it simple • Fail-safe defaults • Use better languages and tools • Think about the end-user

  20. Principle of Fail-Safe Defaults • Policy should list what is allowed, not what is denied • Security configuration should deny all access by default • Oversights show up as “false negatives” • users will quickly complain • Counterexample: Irix OS • Shipped with “xhost +” by default • Allows the world to open windows on your screen and grab the keystrokes you type

  21. This is a potential buffer overflow The attacker can write arbitrary data onto the stack Use Better Languages and Tools • Many software vulnerabilities stem from the use of unsafe languages (mostly C) int main (int argc, char* argv[]) { char buffer[256]; strcpy(buffer,argv[1]); return 0; }

  22. Think About the End User • Many security problems stem from poor user interface design • Famous paper: “Why Johnny Can’t Encrypt” found that ordinary users could not setup encrypted email • Ongoing research: graphical passwords, biometrics, etc.

More Related