Lecture 18 Virtual machines

Lecture 18 Virtual machines - Administrivia Guest lecture...

Info iconThis preview shows pages 1–7. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Administrivia Guest lecture Thursday- Amit Singh (Google): Real-world Operating Systems- Please attend lecture if at all possible Last project due Thursday- No extensions unless all non-SCPD group members at lecture- If staff grants you extension, means only if you attend lecture- We will have a more stringent enforcement mechanism Final Exam- Thursday March 18, 12:15-3:15pm- Open book, covers all 19 lectures (possibly including topics already on the midterm) Televised final review session Friday- Bring questions on lecture material 1/40 Confining code with legacy OSes Often want to confine code on legacy OSes Analogy: Firewalls Hopelessly Insecure Server attacker attacker- Your machine runs hopelessly insecure software- Cant fix itno source or too complicated- Can reason about network traffic Similarly block unrusted code within a machine- By limiting what it can interact with 2/40 Using chroot chroot (char *dir) changes root directory- Kernel stores root directory of each process- File name / now refers to dir- Accessing .. in dir now returns dir Need root privs to call chroot- But subsequently can drop privileges Ideally Chrooted process wouldnt affect parts of the system outside of dir- Even process still running as root shouldnt escape chroot In reality, many ways to cause damage outside dir 3/40 Escaping chroot Re-chroot to a lower directory, then chroot ..- Each process has one root directory, so chrooting to a new directory can put you above your new root Create devices that let you access raw disk Send signals to or ptrace non-chrooted processes Create setuid program for non-chrooted proc. to run Bind privileged ports, mess with clock, reboot, etc. Problem: chroot was not originally intended for security- FreeBSD jail, Linux vserver have tried to address problems 4/40 System call interposition Why not use ptrace or other debugging facilities to control untrusted programs? Almost any damage must result from system call- delete files unlink- overwrite files open/write- attack over network socket/bind/connect/send/recv- leak private data open/read/socket/connect/write ... So enforce policy by allowing/disallowing each syscall- Theoretically much more fine-grained than chroot- Plus dont need to be root to do it Q: Why is this not a panacea? 5/40 Limitations of syscall interposition Hard to know exact implications of a system call- Too much context not available outside of kernel (e.g., what does this file descriptor number mean?)- Context-dependent (e.g., /proc/self/cwd ) Indirect paths to resources- File descriptor passing, core dumps, unhelpful processes Race conditions- Remember difficulty of eliminating TOCCTOU bugs?...
View Full Document

This note was uploaded on 03/13/2010 for the course CS 02523 taught by Professor Davidmieres during the Winter '10 term at A.T. Still University.

Page1 / 40

Lecture 18 Virtual machines - Administrivia Guest lecture...

This preview shows document pages 1 - 7. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online