Chapter 14: Protection and Security

Chapter 14: Protection and Security Prof. Steven A. Demurjian, Sr. † Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818 † These slides have been modified from a set of originals by Dr. Gary Nutt.

Purpose of this Chapter • Answer the Following Questions • How Can Information be Shared? • How Can Information be Protected? • What are Key Concepts and Ideas re. Protection and Security? • How is OS Security Attained? • What Techniques are Available for Security in Programming Languages? • What is Role of Security in Java? • What are Security Issues for Distributed Applications? • Examine both OS Designer and User Perspectives

Glossary of Protection and Security Terms • Access Control List • List of Principals (User, Process, …) Authorized to have Access to Some Object • Authenticate • Verify Identity of Principal Making Request • Authorize • Grant Principal Access to Information • Capability • Unforgeable Ticket as Proof of Authorization of Presenter to Access Named Object • Capability List • List of Protected Objects which Likewise List Authorized Principles

Glossary of Protection and Security Terms • Certify • Verify Accuracy, Correctness, & Completeness of Security/Protection Mechanism • Confinement • Restricting What a Process Can Do to with Authorized Objects • Domain • Objects Currently Accessed by Principal • (De)Encryption • De(Encoding) of Data According to Transformation Key for Transmission/Storage • Grant • Authorize Access to Objects by Principals

Glossary of Protection and Security Terms • Password • Encrypted Character String to Authenticate Identity of Individual • Permission • Form of Allowed Access to Object (R, W, RW) • Principal • Entity (Person/Process/etc.) to Which Authorizations are Granted • Privacy • Ability to Decide Whether, When, and to Whom Information is Released • Propagation • Principal Passing on Authorization to Object to Another Principal

Glossary of Protection and Security Terms • Protected Object • Known Object whose Internal Structure is Inaccessible Except by Protection System • Protection & Security • Mechanisms and Techniques to Control Access to Information by Executing Programs • Revoke • Remove Previously Authorized Access from Principals • Ticket-Oriented • Each Principal Maintains List of Unforgeable Tickets Denoting Objects have been Authorized Glossary from: Saltzer and Schroeder, “The Protection of Information in Computer Systems”, Proc. of IEEE, Vol. 63, No. 9, September 1975.

Fundamental Security Issues • Software Engineers Can Write Complex Programs Limited by Intellectual Capabilities • OS Designer Must Create Protection Scheme that Can’t be Bypassed by Current and Future Software • Users and Processes Initiators • Users have Dedicated and Shared Resources • Resources Shared by User Groups vs. Resources Globally Shared • Users Spawn Processes that Access Resources • Processes May be Local or Remote (on Another Machine Connected via Network) • Protection System of OS Must Support Above According to Organization’s Admin. Policy

Policy & Mechanism • Security Policy Defines Rules for Authorizing Access to Computer and Resources • Who are Users? What are Resources? What Resources are Available to Each User? Etc… • Protection Mechanisms Authenticate • Access to Resources • Insure File and Memory Protection • A Security Policy is an Organizations Strategy to Authorize Access to the Computer’s Resources • Managers have Access to Personnel Files • OS Processes have Access to the Page Table • Security Transcends OS as a Separate Research and Realization for All Types of Systems/Applications

Authentication • User/Process Authentication • Is this User/Process Who It Claims to Be? • Passwords • More Sophisticated Mechanisms • Authentication in Networks • Is this Computer Who It Claims to Be? • File Downloading and Transferring • Obtaining Network Services • What is the Java Promise? • What Does Java Guarantee re. Applets? • What Can Application Do that Applet Can’t?

Recall Bytecode Verification:A Critical Step in the Java Model

Core Security Capabilities of Java • Sandbox and Applet Level Security • Downloaded Applets are Confined in a Targeted Portion of System During Execution • Execution of Untrusted Code in Trusted Way • What is Sandbox? • Area of Web-Browser Dedicated to Applet • Applet Limited to Sandbox to Prohibit Access to Local Machine/Environment • Utilizes Class Loader, Bytecode Verifier, and Security Manager • Three Components Maintain System Integrity • How Does this Occur?

Core Security Capabilities of Java • Class Loader - Only Load Correct Classes • Bytecode Verifier - Classes in Correct Format • Security Manager - Untrusted Classes Can’t Execute Dangerous Instructions nor Access Protected System Resources • Role of Security Managers • Enforces Boundaries of Sandbox • All Java Classes ask Manager for Permission to Perform Certain Operations • Implements/Imposes Appl. Security Policy • Java Interface Class Implementable by Users • Integrated with Exception Handling of Java

Authorization • Ability of Principals to Use Machines, Objects, Resources, etc. • Security Policy Defines Capabilities of Each Principal Against Objects, Resources, etc. • Authorization Mechanism Enforces Policy at Runtime • External Authorization • User Attempts to Access Computer • Authenticate Identify and Verify Authorizations • Internal Authorization • Can Process Access a Specific Resource?

User Authentication • Combination of User ID and Password Universal for Access to Computers • However, Cannot Prevent … • Guessing of Passwords • Stolen and Decrypted Passwords • Masquerading of Intended User • Is User Who they are Supposed to be? • What Extra Information Can User be Asked to Supply? • What About Life Critical Situations (ABCS/FDD)? • Recent Invasion of Engineering Computing • yppasswd File Stolen/Decrypted • S. Demurjian’s Sun Workstation Corrupted

Network Authentication • Computers Must Interact with One Another • Classic Example, Transmitting E-Mail Msgs. • Does Transferring Computer have Right to Store a File on Another Computer? • Viruses: Passive Penetrating Entity • Software Module Hidden in Another Module • When Container Executed, Virus Can Penetrate and Wreak Havoc • Worms: Active Penetrating Entity • Actively Seeks to Invade Machine • Morris’s Worm Penetrated via Unix Finger • Passed String that Executed Allocated Memory • Destroyed Runtime Stack/Allowed Worm Execute

Sharing Parameters Process Calls Proc. in Another Addr. Space Callee Mods. Params. Caller’s Addr. Space Mod. After Return Confinement (Glossary) Allocating Rights Ability of Process to Pass on Resource Rights to Process Temporary Allocation Trojan Horse Server Takes Advantage of Client to Access Its Resources for Own Use Internal Access AuthenticationClasses of Protection Problems Process B Process C Read Write Write Read Resource W Resource X Resource Y Process A Resource Z

Lampson’s Protection Model • Active Parts (e.g., Processes) • Operate in Different Domains • Subject (Principal) is a Process in a Domain • Passive Parts are Called Objects • Process Access Objects According to Rights that Process has to do so • Note: Not “Object-Oriented” Objects! • Want Protection Mechanism to Implement Different Security Policies for Subjects to Access Objects • Many Different Policies Must Be Possible • Policy May Change Over Time

S desires a access to X A Protection System Subjects Objects Protection State a S X State Transition Rules Policy • Protection State Reflects Current Ability Access X • Authorities can Change • What are Rules for Changing Authority? • How are Rules Chosen?

Protection System Example (S, a, X) Access authentication a Monitor X X S S a a Access matrix S X • S Desires a Access to X • Captures Protection State • Generates Unforgeable ID • Checks Access Against the Protection State • How are Rules Chosen?

Access Matrix & Protection State Example S1 S2 S3 F1 F2 D1 D2 S1 control block wakeup owner control owner read* write* seek owner S2 control stop owner update owner seek* S3 control delete execute owner • Access Matrix of Subjects and Subjects/Objects • Specifies Rights Authorized to Subject on Each Subject and Object • Protection System Must Check Access Matrix Prior to Allowing Operation to Occur • (S2, update, F2) Allowed • (S2, execute, F2) Denied

Policy Rules for Protection State • Policy Rules Control Means by Which Protection System can Alter the Protection State • Rules Specify Protection State Transitions • Indicate How Process transfers, deletes, & grants Privileges • Policy Rules and Transferring/Granting are Dangerous --- Why? • May Allow Process (Subject/Principal) to Pass on Privilege to Another Process • That Privilege May Violate Security Policy • Need to Prevent Privilege Being Passed on (Propagated) to Other Process

Policy Rules Example S1 S2 S3 F1 F2 D1 D2 S1 control block wakeup owner control owner read* write* seek owner S2 control stop owner update owner seek* S3 control delete execute owner Rules for a Particular Policy Rule Command by S0 Authorization Effect 1 transfer(a|a*) to (S, X) a*A[S0, X] A[S, X] = A[S, X]{a|a*} 2 grant(a|a*) to (S, X) ownerA[S0, X] A[S, X] = A[S, X]{a|a*} 3 delete a from (S, X) controlA[S0, S] A[S, X] = A[S, X]-{a} or ownerA[S0, X]

Implementing Internal Authorization • What Implementations are Cost Effective for Model? • How can an Access Matrix be Implemented Effectively? • What is Role of a Programming Language in Support of Implementing Authorization? • Objectives and Goals • Access Matrix Must be in Secure Storage Media • All Access Must be via Protection Monitor • Authorization by Subject/Request not by Parameter to Procedure Call • Monitor as Protected Process

Protection Domains • Lampson’s Model Uses Processes and Domains • How is a Domain Implemented? • Supervisor/User Hardware Mode Bit • Software Extensions -- Rings • Inner Rings have Higher Authority • Ring 0 Corresponds to Supervisor Mode • Rings 1 to S have Decreasing Protection, and are Used to Implement the OS • Rings S+1 to N-1 have Decreasing Protection, and are Used to Implement Applications

Protection Domains (continued) • Ring Crossing is a Domain Change • Inner Ring Crossing  Rights Amplification • Process Acquires “Stronger” Rights • Process Must Execute in Inner Ring Domain • Specific Gates for Crossing • Protected by an Authentication Mechanism • Outer Ring Crossing Uses Less-Protected Objects • No Authentication • Need a Return Path • Used in Multics and Intel 80386 (and Above) Hardware

Implementing Access Matrix • Usually a Sparse Matrix • Too Expensive to Implement as a Table • Implement as a List of Table Entries • Available in Java as part of Security API • Column Oriented List is Called an Access Control List (ACL) • List Kept at the Object • UNIX File Protection Bits are One Example • Row Oriented List is a Called a Capability List • List Kept With the Subject (I.e., Process) • Kerberos Ticket is a Capability • Mach Mailboxes Protected With Capabilities

More on Capabilities • Provides an Address to Object From a Very Large Address Space • Possession of Capability Represents Authorization for Access • Implied Properties: • Capabilities Must Be Very Difficult to Guess • Capabilities Must Be Unique and Not Reused • Capabilities Must Be Distinguishable From Randomly Generated Bit Patterns

Kerberos • Kerberos • Assumes Tampering of Information Flowing over Network • OSs on Two Machines Not Necessarily Secure • How Does Kerberos Work? • Process on Client Wants Services of Process on Server • Network is Medium for Communication • Kerberos Provides Authentication Server and Protocol • Client/Server can Transmit Authenticated Messages • Authentication Server Must be Trusted!

Kerberos Encrypted for client Encrypted for server Authentication Server 1. Client Asks for Credentials of Server 2. Return Credentials as Ticket & Session Key Encrypted Session Key 3. Client Decrypts Ticket/Session Key and Retain Copy Client Ticket Client ID 4. Client Sends Copy of Ticket and Encrypted Files to Server Session Key Ticket Session Key Server Client ID Session Key 5. Server Decrypts to Yield Secure Copy of Client ID and Session Key Client ID Session Key

Cryptography • Information Can Be Encoded Using a Key it is Written (or Transferred) -- Encryption • Information is Then Decoded Using a Key When it Is Read (or Received) -- Decryption • Very Widely Used for Secure Network Transmission • Mathematical Basis - Prime Number Generation encryption plaintext ciphertext decryption

More on Cryptography plaintext plaintext Ke Kd C = EKe(plaintext) Encrypt Decrypt Invader Side information plaintext

Cryptographic Systems Cryptographic Systems Modern Systems Conventional or Symmetric Systems • Ke and Kd are essentially the same Private Key Public Key • Ke and Kd are private • Ke is public • Kd is private

Non-OS Security Issues and Approaches • Security Capabilities of Java • What is Available? • JVM vs. Security API • Security and Distributed Computing • Classic and Emerging Security Solutions • MAC vs. DAC vs. URBS • Discretionary Access Control/Role Based Security • How is Security Realized at PL Level? • OO-Based Security Solution • Java vs. Other OOPLs • Outlining the Future of Security

Security Capabilities of Java Digital Signatures and JAR Files • When Can Applets Become Applications? • Trusted Publisher (Originator of Applet) • Signed Applet is Authenticated • Java Security Manager May Allow Applet out of Sandbox to be Application • How is Information Transmitted and Exchanged? • JAR: Archived (Compressed) Files • Bundling of Code/Data into Java Archive • Associated Digital Signature for Verification • Transmission via Object Serialization

Security Capabilities of Java Message Digest and Key Management • Message Digest • “Speedy” Alternative to Public Key Encryption • Generation of a Short, Unique Representation of Message that is Encrypted and Used as Digital Signature • Message Digest Algorithms (MD5, SHA, …) • Key Management • Integrated Key Management for Java Programs and Applets • Ability to Encode/Decode • Java API for Generating, Certifying, and Manipulating Keys

Security Capabilities of JavaAccess Control List (ACLs) • Control Access to Resources by Permissions • Classical Security Technique for • Data Structure to Protect Resources • SE to Define Read/Write Permissions Based on Users and User Groups • Manipulation of List of Access Privileges • Support Negative and Positive Permissions • Paradigm of Individual vs. Group • Individual Permissions Override Group • Implementation at Programming Language Level for Functions Typically Found in OS

Access Control Lists in java.security API • ACLs Can be Utilized to Control Method Access • ACL Composed of ACL Entries • ACL Entry Set of Permissions (Allowable Method Accesses) for Each UR • Utilize ACLs as Implementation Vehicle for URSA, BEA, and Other Approaches • java.security.acl.ACL Provides Following: • addEntry() and removeEntry() • CheckPermission(): Can UR Utilize Method? • add-, check-, and remove- Permission() • SetPrincipal: UR for which Permissions (Methods) are Assigned/Prohibited • Etc…

Security for Distributed Computing COTS Database Legacy Legacy COTS NETWORK Java Client Java Client Legacy Database COTS How is Security Handled for Individual Systems? What if Security Never Available for Legacy/COTS/Database? Security Issues for New Clients? New Servers? Across Network? What about Distributed Security?

Security and Distributed Computing • Authentication • Is the Client who S/he Says they are? • Authorization • Does the Client have Permission to do what S/he Wants? • Privacy • Is Anyone Intercepting Client/Server Communications? • Enforcement Mechanism • Centralized and Distributed “Code” • Enforces Security Policy at Runtime

Security and Distributed Computing • Assurance • Are the Security Privileges for Each Client Adequate to Support their Activities? • Do the Security Privileges for Each Client Meet but Not Exceed their Capabilities? • Consistency • Are the Defined Security Privileges for Each Client Internally Consistent? • Least-Privilege Principle: Just Enough Access • Are the Defined Security Privileges for Related Clients Globally Consistent? • Mutual-Exclusion: Read for Some-Write for Others

Classic and Emerging Security Solutions • Mandatory Access Control (MAC) • Bell/Lapadula Security Model • Security Levels for Data Items • Access Based on Clearance of User • Discretionary Access Control (DAC) • Richer Set of Access Modes • Focused on Application Needs/Requirements • User-Role Based Security (URBS) • Variant of DAC • Responsibilities of Users Guiding Factor • Facilitate User Interactions while Simultaneously Protecting Sensitive Data

Security in Software ApplicationsFocusing on DAC and URBS • Extensive Published Research (Demurjian, et al) in Last Five Years for DAC/URBS for OO • Recent Efforts in • Automatically Generatable and Reusable Enforcement Mechanisms • Software Architectures (Client/Server) for Consistency and Assurance in URBS • Premise: • Customizable Public Interface of Class • Access to Public Interface is Variable and Based on User Needs and Responsibilities • Only Give Exactly What’s Needed and No More

Focusing on DAC and URBS • Public Interface Concept of Class • Union of All Privileges for All Potential Users • No Explicit way to Prohibit Access • Once Public - Can’t Prohibit Access • Responsibility of Software Engineer Class PatientRecord { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); etc… } For MDs Only For MDs and Nurses For Admitting

Focusing on DAC and URBS • We’ve Explored DAC/URBS for OO Systems and Applications • Potential Public Methods on All Classes • Role-Based Approach: • User Role Determines which Potential Public Methods are Available • Automatically Generate Mechanism to Enforce the Security Policy at Runtime • Allow Software Tools to Look-and-Feel Different Dynamically Based on Role • Approaches have Stressed Exploiting OO/PL Capabilities (Inheritance, Exceptions, Generics) While Limiting SW Engineers Knowledge

User-Role Subclassing Approach in Java public class MD_PatientRecord extends PatientRecord { public: set_payment_mode() {return;} } public class PatientRecord { private: Data/Methods; public: write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); } public class Nurse_PatientRecord extends PatientRecord { public: write_medical_history() {return;} write_prescription() {return;} set_payment_mode() {return;} } • Subclasses of PatientRecord Turn Off Methods Not Available • Software Creates Nurse_PatientRecord or MD_PatientRecord Instance • Method Calls Against Subclass Return Null for Turned Off Methods • GUI Tool Works Differently Based on User Role with Same Code

A Basic Exception Approach in Java Exploit Exception Handling for Dynamic Behavior of Tool by Role public class PatientRecord { // private data has been omitted public void set_payment_mode(int mode) { // Insurance_Mode is private data of PatientRecord return(set_int_check_valid_UR(Insurance_Mode, mode)); } public void set_int_check_valid_UR(int i1, int i2) { try { // See if Current_User can execute method check_UR(); } // catch block to process raised exceptions catch (Unauthorized_UR UR_Exception) { system.out.println(“Attempt to access by unauthorized UR”); } i1 = i2; } public void Check_UR()throws Unauthorized_UR { // Incomplete - only to illustrate the concepts!!! if (compareTo(Current_User.Get_User_Role(), “Admitting”)!=0) throw new Unauthorized_UR(); // raises exception } } Once the Current_User is Set, the Rest of the Tool Code Works without that Knowledge Thus, Software Engineers Don’t Need to Know or See the DAC/ URBS Details!!

A Generic Exception Approach Employ a Generic Security Class to Embody the Common Security Code Needed by All Application Classes Reduces Redundancy and Increases Reuse Each Application Class that Requires Security Includes and Customizes the Gen_Security Class

Applicability of URBS Approaches • All Supported by C++, Eiffel, and Ada95 • User-Role Subclassing Approach • Requires SW Engineer to Understand URBS • Supported by Java • Basic Exception Approach • Minimizes SW Engineer Exposure to URBS • Elegant in Java Due to Exceptions • User-Role Class Library Approach (not shown) • Requires Multiple Inheritance • Unsupported in Java - only Design-Level Multiple Inheritance via Interfaces • Generic Exception Approach • Exceptions plus Generics Improves Reuse • Unsupported in Java - no Templates

Security for OO Legacy/COTS OO Classes that form the ProgrammingInterface to Legacy/COTs, e.g., PatientRecord OO Classes that form the ProgrammingInterface to Legacy/COTs, e.g., PatientRecord PatientRecord_Exception Class Extends PatientRec with try/catch/throw Nurse_PatientRecord and MD_PatientRecord Classes Customer/User Applications Against PatientRecord_Excp Customer/User Applications Against Nurse/MD Classes User-Role Subclassing Approach Basic Exception Approach • For OO Legacy/COTS, High Likelihood of Class Based Programming Interface • Utilize Reviewed DAC/URBS Approaches:

Security for Non-OO Legacy/COTS Set of System Functions that form the Pgmmg.Interface to Legacy or COTS Set of System Functions that form the Pgmmg.Interface to Legacy or COTS OO Wrapper of Classes with Methods that Invoke Functions OO Wrapper of Classes with Methods that Invoke Functions Customer/User Applications Against Exception Classes Exception Classes Extend OO Wrapper Classes-try/catch/thw User-Role Subclasses , e.g., MD_PatientRecord for Customer/User Applications Against User-Role Subclasses User-Role Subclassing Approach Basic Exception Approach • For Non-OO Legacy/COTS, Programming Interface Likely a Set of System Functions • Utilize Reviewed DAC/URBS Approaches:

Chapter 14: Protection and Security