Download Lecture 15 Designing Trusted Operating Systems Thierry Sans

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Burroughs MCP wikipedia , lookup

Spring (operating system) wikipedia , lookup

Process management (computing) wikipedia , lookup

Distributed operating system wikipedia , lookup

Unix security wikipedia , lookup

Security-focused operating system wikipedia , lookup

Transcript
Lecture 15
Designing Trusted
Operating Systems
Thierry Sans
15-349: Introduction to Computer and Network Security
Anatomy of an operating system
Concept of Kernel
➢
Definition
•
➢
Component that provides an communication layer
between the hardware and the software
The kernel is in charge of
•
Managing the memory
•
Managing processes (allocation and synchronization)
•
Managing data resources (filesystem, I/O devices)
•
Managing communication
•
... and so in charge of enforcing security mechanisms
Two design philosophies
➢
Monolithic Kernels
•
➢
Like the Linux kernel
Microkernels
•
•
Like the Windows NT or BSD kernels
(even though considered as hybrid kernels)
Discussion between L. Torvalds and A. Tanenbaum
Monolithic kernels
➢
Philosophy
•
➢
All OS services run along with the main kernel
thread in the same memory area
Pros and Cons
•
Easier to design
•
Dependencies between components
Microkernels
➢
Philosophy
•
•
•
➢
Implement minimal OS services for memory and
process management
Other services (I/O, networking ...) are
implemented as servers in the user-space memory
The first general-purpose microkernel was Mach
(Carnegie Mellon University)
Pros and Cons
•
Easy to maintain
•
Many system calls that can slow down the system
Where the security should be ...
Open Design principle
➢
Open Design
•
•
•
A protection mechanism must not depend on the
fact that its design is secret
Kerckhoffs' principle
Unfortunately wrong designs, that violates this
principle, exist in practice
•
See lecture 17 on Digital Rights Management (DRM)
Design principles to restrict privileges
➢
Least Privilege
•
➢
Separation of privileges
•
➢
Each user (understand each program) must have the
smallest privilege set needed to operate
A business process must be split in different
elementary tasks with minimum privileges
Least Common Mechanism
•
Reduce and control the exchange of information
between shared objects and resources
(potential channels for information leakage)
Access Control design principles
➢
Permission based
•
➢
Complete mediation
•
➢
Identifies what can be permitted and any
unidentified access (“close world” hypothesis)
Every access attempt must be checked and cannot
be circumvent
Trusted path
•
Access control mechanisms cannot be spoofed or
intercepted by a malicious user program
The “keep it simple and usable” principles
➢
Economy of mechanism
•
•
➢
The design of a security mechanism must be small
and easy to analyze
Increasing the reliability in security mechanisms
Ease of use
•
•
A security mechanism must be easy to use
Avoiding users and/or administrators to disable
security mechanisms
Security features for Operating Systems
➢
Identification and Authentication of users
➢
Protection of the execution context
•
➢
➢
Focus: protecting the processes
Protection of general objects (access control)
•
Focus: the reference monitor
•
Focus: the object reuse attack
Protection of administrative data and processes
•
Focus: managing the logs
Protection of the execution context
➢
Protection of the memory
•
➢
Already seen in lecture 12
In a concurrent context, a process needs to
•
Access to some resources
•
Synchronize with other processes
•
Be executed
•
All of these must be controlled by the operating
system
Focus: Protecting processes
➢
Enforced Sharing
•
➢
Interprocess communication and Synchronization
•
➢
Must have access to resources as appropriate
Must have access to synchronization mechanisms
Guaranteed Fair Service
•
Must get a fair CPU allocation time to run
(preventing starvation)
Protection of general objects
➢
Two kind of objects to consider
•
Static objects
•
•
Dynamic objects
•
➢
File and I/O devices
Mainly used for synchronization and sharing between
concurrent programs
The “Reference Monitor”
•
In charge of enforcing the access control policy
(DAC and/or MAC)
Focus: the concept of “Reference Monitor”
➢
Objective
•
•
➢
Controlling access to objects
Not necessarily a single piece of code
but rather a collection of protection mechanisms
The reference Monitor must be
•
Tamperproof
- impossible to weaken or disable
•
Unbypassable
- always invoked on every access
•
Analyzable
- small enough to be easily validated
Focus: The Object Reuse attack
➢
Reusable objects
•
➢
Possible counter-measure
•
➢
“Free” disk or memory space can contain old (and
sensitive) data that have been previously disallocated
“Clear” the portion of memory by rewriting it with
garbage code
A more general problem
•
Magnetic remanence
•
How to discard old magnetic devices?
Security features for administration
➢
Protect security configuration data and
processes
•
•
➢
Definition of system (and/or security) administrators
Configuring (even implementing) an administration
model for access control
Setup and protect accountability mechanisms
•
•
Useful to detect a misconfiguration or an attack
(remember an attack is not necessarily disruptive)
Useful to recover from attack and take countermeasures
Focus: Managing and analyzing logs
➢
Problem
•
Logs are difficult to manage and analyze in practice
•
➢
For instance, a program can cause hundreds of access
creating a huge volume of data making it hard to analyze
Solution
•
•
Classify the logs according to their sensitivity level
Analyzed the logs using specialized audit programs
(or intrusion detection programs)
•
Passive (off-line or on-line) raise an alert
•
Pro-active (on-line) block the access (IPS)
Strengthening the security of an OS
➢
Trust Computing Base Operating Systems make
a distinction between TCB and non-TCB
components of the kernel
•
•
TCB components that handles the security of the
system and that must not be tampered by users
(nor even administrators)
Non-TCB components that will not jeopardize the
security of the system if tampered by the users (or
administrators)
Example of Trusted-OS: SELinux
➢
Security-Enhanced Linux (SELinux)
•
•
Developed by the NSA to implements the multilevel
military security policy proposed by the US DoD
First released as a Linux patch, SELinux is now fully
integrated into the Linux Kernel (version 2.6)
Virtualization
➢
Objective
•
➢
Provide a constraint execution environment by
simulating a collection resources
Examples
•
The Java virtual machine
•
Virtual Memory Space
•
Virtual Machines
Virtual Machines
Conclusion
➢
The best way to learn more ....
... is to take a closer look at your OS
•
•
Play with your OS and learn how it has been built
Identify the security mechanims and understand
how they contribute to secure the system
•
Play with other OS and compare them
•
Learn about the details and found the breach
•
Create a proof of concept attack (exploit) and
become an “ethical” hacker
Open question ...
Policy
Administrates
How can I be sure that Bob will not
tamper its system to bypass access
control mechanisms and have a full
access to my data?
Administrates