1 cs691 chow C. Edward Chow Design Principles for Secure Mechanisms CS591 – Chapter 5.4 Trusted OS Design CS691 – Chapter 13 of Matt Bishop.

Slides:



Advertisements
Similar presentations
November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #12-1 Chapter 12: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Advertisements

Michelle J. Gosselin, Jennifer Schommer Guanzhong Wang.
Chapter One The Essence of UNIX.
CSCI 530 Lab Firewalls. Overview Firewalls Capabilities Limitations What are we limiting with a firewall? General Network Security Strategies Packet Filtering.
1 Design Principles CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute April 13, 2004.
Lecture 2 Page 1 CS 236, Spring 2008 Security Principles and Policies CS 236 On-Line MS Program Networks and Systems Security Peter Reiher Spring, 2008.
19.1 Silberschatz, Galvin and Gagne ©2003 Operating System Concepts with Java Chapter 19: Security The Security Problem Authentication Program Threats.
CMSC 414 Computer and Network Security Lecture 12 Jonathan Katz.
Design Principles Overview Principles Least Privilege Fail-Safe Defaults Economy of Mechanism Complete Mediation Open Design Separation of Privilege Least.
Chapter 1  Introduction 1 Overview  What is a secure computer system?  Concerns of a secure system o Data: Privacy, Integrity, Availability o Users:
CS-550 (M.Soneru): Protection and Security - 1 [SaS] 1 Protection and Security.
(Breather)‏ Principles of Secure Design by Matt Bishop (augmented by Michael Rothstein)‏
CMSC 414 Computer and Network Security Lecture 9 Jonathan Katz.
Silberschatz, Galvin and Gagne  Operating System Concepts Module 19: Security The Security Problem Authentication Program Threats System Threats.
April 1, 2004ECS 235Slide #1 Chapter 1: Introduction Components of computer security Threats Policies and mechanisms The role of trust Assurance Operational.
Guide To UNIX Using Linux Third Edition
Lecture 10: Security Design Principles CS 436/636/736 Spring 2012 Nitesh Saxena.
C. Edward Chow Presented by Mousa Alhazzazi C. Edward Chow Presented by Mousa Alhazzazi Design Principles for Secure.
CMSC 414 Computer and Network Security Lecture 17 Jonathan Katz.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Application Layer Functionality and Protocols Network Fundamentals – Chapter.
Course 201 – Administration, Content Inspection and SSL VPN
Intranet, Extranet, Firewall. Intranet and Extranet.
Lecture 18 Page 1 CS 111 Online Design Principles for Secure Systems Economy Complete mediation Open design Separation of privileges Least privilege Least.
Computation for Physics 計算物理概論 Introduction to Linux.
Csci5233 Computer Security1 Bishop: Chapter 27 System Security.
World Wide Web Hypertext model Use of hypertext in World Wide Web (WWW) WWW client-server model Use of TCP/IP protocols in WWW.
CMSC 414 Computer (and Network) Security Lecture 14 Jonathan Katz.
FTP Server and FTP Commands By Nanda Ganesan, Ph.D. © Nanda Ganesan, All Rights Reserved.
Hour 7 The Application Layer 1. What Is the Application Layer? The Application layer is the top layer in TCP/IP's protocol suite Some of the components.
Software Security and Security Engineering (Part 2)
Chapter 1 Overview The NIST Computer Security Handbook defines the term Computer Security as:
CMSC 414 Computer and Network Security Lecture 10 Jonathan Katz.
Application Services COM211 Communications and Networks CDA College Theodoros Christophides
Access Control. What is Access Control? The ability to allow only authorized users, programs or processes system or resource access The ability to disallow.
Computer Networking From LANs to WANs: Hardware, Software, and Security Chapter 13 FTP and Telnet.
Linux Security. Authors:- Advanced Linux Programming by Mark Mitchell, Jeffrey Oldham, and Alex Samuel, of CodeSourcery LLC published by New Riders Publishing.
Lecture slides prepared for “Computer Security: Principles and Practice”, 3/e, by William Stallings and Lawrie Brown, Chapter 1 “Overview”. © 2016 Pearson.
CS 3830 Day 9 Introduction 1-1. Announcements r Quiz #2 this Friday r Demo prog1 and prog2 together starting this Wednesday 2: Application Layer 2.
(Breather)‏ Principles of Secure Design by Matt Bishop (augmented by Michael Rothstein)‏
Trusted Operating Systems
Design Principles and Common Security Related Programming Problems
Fall 2008CS 334: Computer SecuritySlide #1 Design Principles Thanks to Matt Bishop.
June 1, 2004Computer Security: Art and Science © Matt Bishop Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe.
LINUX Presented By Parvathy Subramanian. April 23, 2008LINUX, By Parvathy Subramanian2 Agenda ► Introduction ► Standard design for security systems ►
1 Chapter 12: Design Principles Overview –There are principles for many kinds of design Generally, a design should consider: Balance, Rhythm, Proportion,
June 1, 2004© Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Slide #13-1 Design Principles CS461/ECE422 Computer Security I Fall 2008 Based on slides provided by Matt Bishop for use with Computer Security: Art and.
Software Security II Karl Lieberherr. What is Security Enforcing a policy that describes rules for accessing resources. Policy may be explicit or implicit.
1 Saltzer [1974] and later Saltzer and Schroeder [1975] list the following principles of the design of secure protection systems, which are still valid:
1 Design Principles CS461 / ECE422 Spring Overview Simplicity  Less to go wrong  Fewer possible inconsistencies  Easy to understand Restriction.
Chapter 29: Program Security Dr. Wayne Summers Department of Computer Science Columbus State University
CS457 Introduction to Information Security Systems
Lecture 10: Security Design Principles
Security+ All-In-One Edition Chapter 1 – General Security Concepts
Software Security II Karl Lieberherr.
Module 4 Remote Login.
Chapter 13: Design Principles
IS3440 Linux Security Unit 6 Using Layered Security for Access Control
IIS.
Chapter 1: Introduction
Chapter 27: System Security
Announcement Project 2 Due Project 3 will be out this weekend.
Design Principles and Security related problem
Computer Security: Art and Science, 2nd Edition
Chapter 29: Program Security
Chapter 13: Design Principles
Operating System Concepts
Security Principles and Policies CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
Preventing Privilege Escalation
Design Principles Thanks to Matt Bishop 2006 CS 395: Computer Security.
Presentation transcript:

1 cs691 chow C. Edward Chow Design Principles for Secure Mechanisms CS591 – Chapter 5.4 Trusted OS Design CS691 – Chapter 13 of Matt Bishop

2 cs691 chow Design Principles for Security Mechanisms Based on the ideas of simplicity and restriction. J. Saltzer and M. Schroeder Proceeding of IEEE 1975 describes 8 principles for security mechanism Least Privileges Fail-Safe Defaults Economy of Mechanism Complete Mediation Open Design Separation of Privilege Least Common Mechanism Psychological Acceptability Based on the ideas of simplicity and restriction. J. Saltzer and M. Schroeder Proceeding of IEEE 1975 describes 8 principles for security mechanism Least Privileges Fail-Safe Defaults Economy of Mechanism Complete Mediation Open Design Separation of Privilege Least Common Mechanism Psychological Acceptability

3 cs691 chow Overview Simplicity makes designs and mechanisms easy to understand. Simplicity reduces the potential for inconsistencies within a policy or set of policies. Minimizing the interaction of system components minimizes the number of sanity checks on data being transmitted among components. Restriction minimizes the power of an entity. The entity can access only information it needs. Only communicates with other entities when necessary, and in as few and narrow ways as possible. Simplicity makes designs and mechanisms easy to understand. Simplicity reduces the potential for inconsistencies within a policy or set of policies. Minimizing the interaction of system components minimizes the number of sanity checks on data being transmitted among components. Restriction minimizes the power of an entity. The entity can access only information it needs. Only communicates with other entities when necessary, and in as few and narrow ways as possible.

4 cs691 chow Examples Sendmail reads configuration data from a binary file, compiled (freezing) from a text version of the configuration file. 3 interfaces: The mechanism that edits the text configuration file. The mechanism that comples (freezes) the text file. The mechanism sendmail used to read the binary (frozen) file. Version control problem. What if text configuration file is newer than the binary file. Sendmail warns the user? Should sendmail rechecks the parameters in configuration file? If the compiler allows the string name as default UID (daemon) while the sendmail accepts only integer as UID, the input routine of sendmail will read “daemon” and return error value 0. 0 as UID is root! Sendmail reads configuration data from a binary file, compiled (freezing) from a text version of the configuration file. 3 interfaces: The mechanism that edits the text configuration file. The mechanism that comples (freezes) the text file. The mechanism sendmail used to read the binary (frozen) file. Version control problem. What if text configuration file is newer than the binary file. Sendmail warns the user? Should sendmail rechecks the parameters in configuration file? If the compiler allows the string name as default UID (daemon) while the sendmail accepts only integer as UID, the input routine of sendmail will read “daemon” and return error value 0. 0 as UID is root!

5 cs691 chow Example for Avoiding Inconsistency in Policies Policy rule1: TA needs any cheating. Policy rule2: ensure the privacy of student files. Case: TA reminds student file not submitted. Student ask TA to look for files in student’s directory. TA finds two files. Unsure which files. TA reads the first file, it turns out to be written by other TA reads the 2 nd file, it turns out identical except names. TA reports the cheating. Student charges TA violating his privacy by reading the first set of files. Policy rule1: TA needs any cheating. Policy rule2: ensure the privacy of student files. Case: TA reminds student file not submitted. Student ask TA to look for files in student’s directory. TA finds two files. Unsure which files. TA reads the first file, it turns out to be written by other TA reads the 2 nd file, it turns out identical except names. TA reports the cheating. Student charges TA violating his privacy by reading the first set of files.

6 cs691 chow Examples of Restrictions Government officials are denied access to info for which they have no need (the “need to know” policy). They cannot communicate that which they do not know. Case: Imparting information by not communicating Bernstein and Woodward, Watergate reporters, ask the source to hang up if information was inaccurate, remain on the line if the information was accurate. Government officials are denied access to info for which they have no need (the “need to know” policy). They cannot communicate that which they do not know. Case: Imparting information by not communicating Bernstein and Woodward, Watergate reporters, ask the source to hang up if information was inaccurate, remain on the line if the information was accurate.

7 cs691 chow Principle of Least Privileges A subject should be given only those privileges that it needs in order to complete its task. Exception case?: for certain action, subject’s access right can be augmented but relinquished immediately on completion of the action. Append right? vs. write right In practice, most system does not have the granularity of privileges and permission required to apply this principle precisely. The designers of mechanisms try their best? Does the root/administrator user concept violate the above rule? A subject should be given only those privileges that it needs in order to complete its task. Exception case?: for certain action, subject’s access right can be augmented but relinquished immediately on completion of the action. Append right? vs. write right In practice, most system does not have the granularity of privileges and permission required to apply this principle precisely. The designers of mechanisms try their best? Does the root/administrator user concept violate the above rule?

8 cs691 chow Example of Tomcat User Access Control Files User with Admin role can start/shutdown the Tomcat web server. User with Manage role can insert/delete web applications. User with cs526stu role can read cs526 web pages. When the user first accesses the web site, the user will be asked for the username and password. User with Admin role can start/shutdown the Tomcat web server. User with Manage role can insert/delete web applications. User with cs526stu role can read cs526 web pages. When the user first accesses the web site, the user will be asked for the username and password.

9 cs691 chow Mail Server Access Rights Mail server accepts mail from Internet and copies the msgs to a spool directory. A local server will complete delivery. Mail server needs rights to access network port 25, To create files in the spool directory To alter those files (copy msg to file, rewrite delivery address if needed, incase of aliases?) It should surrender the right when finishes. It should not access the users’ files. Local server only has the read and delete access to spool direcotry. The admin should only be able to access subjects and objects involved in mail queueing and delivery, in case it is compromised?? Mail server accepts mail from Internet and copies the msgs to a spool directory. A local server will complete delivery. Mail server needs rights to access network port 25, To create files in the spool directory To alter those files (copy msg to file, rewrite delivery address if needed, incase of aliases?) It should surrender the right when finishes. It should not access the users’ files. Local server only has the read and delete access to spool direcotry. The admin should only be able to access subjects and objects involved in mail queueing and delivery, in case it is compromised??

10 cs691 chow Principle of Fail-Safe Defaults Unless a subject is given explicit access to an object, it should be denied access to that object. If the subject is not able to complete its action/task, it should undo those changes it made in the security state of the system before it terminates. If the program fails, the system is still safe. What happens if the program crashes, not fails? Mail server should not write msg to a different directory than spool (if it is full). It should just close the network connection, issue an error msg and stop. Unless a subject is given explicit access to an object, it should be denied access to that object. If the subject is not able to complete its action/task, it should undo those changes it made in the security state of the system before it terminates. If the program fails, the system is still safe. What happens if the program crashes, not fails? Mail server should not write msg to a different directory than spool (if it is full). It should just close the network connection, issue an error msg and stop.

11 cs691 chow Principle of Economy of Mechanism Security mechanisms should be as simple as possible. Fewer errors; less checking and testing Bad example: Mechanism on host A allows access based on the ident protocol. Ident protocol sends the user name associated with a process that has a TCP connection to a remote host. A compromised host can send any identity. Interface to other modules are particular suspect. Example of DoS attack using Finger protocol. It returns infinite streams of characters. Client will crash. Security mechanisms should be as simple as possible. Fewer errors; less checking and testing Bad example: Mechanism on host A allows access based on the ident protocol. Ident protocol sends the user name associated with a process that has a TCP connection to a remote host. A compromised host can send any identity. Interface to other modules are particular suspect. Example of DoS attack using Finger protocol. It returns infinite streams of characters. Client will crash.

12 cs691 chow Principle of Complete Mediation All accesses to objects be checked to ensure that they are allowed. Unfortunately, most OS will check the access right when the object was “open”, but will not check access right again when the client program reads. The OS cached the results of the first check. If the owner disallows reading the file after the file descriptor is issue, the kernel will still allow the client process to read. DNS server caches Domain name-IP address entries. The attacker can “poison” the cache with incorrect entries, a host will be routed to a spoof site. All accesses to objects be checked to ensure that they are allowed. Unfortunately, most OS will check the access right when the object was “open”, but will not check access right again when the client program reads. The OS cached the results of the first check. If the owner disallows reading the file after the file descriptor is issue, the kernel will still allow the client process to read. DNS server caches Domain name-IP address entries. The attacker can “poison” the cache with incorrect entries, a host will be routed to a spoof site.

13 cs691 chow Principle of Open Design The security of a mechanism should not depend on the secrecy of its design or implementation. Attack such as disassembly and analysis, dumpster- diving for source code, Isn’t “Security through obscurity” a good principle? Example: cryptograph software, algorithms. How about proprietary softare/trade secrets? The famous Content Scramble System (CSS) break by Norway group. Plaitiff’s lawyer filed law suit containing the source code! The security of a mechanism should not depend on the secrecy of its design or implementation. Attack such as disassembly and analysis, dumpster- diving for source code, Isn’t “Security through obscurity” a good principle? Example: cryptograph software, algorithms. How about proprietary softare/trade secrets? The famous Content Scramble System (CSS) break by Norway group. Plaitiff’s lawyer filed law suit containing the source code!

14 cs691 chow Principle of Separation of Privilege A system should not grant permission based on a single condition. Separation of duty principle. Company checks > 75K signed by two officers. Berkeley Unix allows a user to change to root if The user knows root password. The user is in the wheel group (the group with GID 0). A system should not grant permission based on a single condition. Separation of duty principle. Company checks > 75K signed by two officers. Berkeley Unix allows a user to change to root if The user knows root password. The user is in the wheel group (the group with GID 0).

15 cs691 chow Principle of Least Common Mechanism Mechanisms used to access resources should not be shared. Virtual machie/memory concept follows this. Internet access route should not be shared? How to restrict the attackers’ access to the segment of Internet connected to a web site? Purdue SYN intermediary system. Secure Collective Defense Project. Mechanisms used to access resources should not be shared. Virtual machie/memory concept follows this. Internet access route should not be shared? How to restrict the attackers’ access to the segment of Internet connected to a web site? Purdue SYN intermediary system. Secure Collective Defense Project.

16 cs691 chow Principle of Psychological Acceptability Security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present. Example SSH. Example: not allow access after 3 tries. Security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present. Example SSH. Example: not allow access after 3 tries.