Security in Operating Systems Csilla Farkas Associate Professor farkas@cec.sc

1. Security in Operating Systems Csilla Farkas Associate Professor farkas@cec.sc.edu http://www.cse.sc.edu/~farkas Computer Science and Engineering

2. Recent Security Incidents • Oct. 2013, Microsoft Security Bulletin MS13-081 – Critical: Vulnerabilities in Windows Kernel-Mode Drivers Could Allow Remote Code Execution (2870008) • Aug. 2013, Microsoft Security Bulletin MS13-063 – Important: Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege (2859537) • Recommendation. Most customers have automatic updating enabled and will not need to take any action Computer Science and Engineering

3. MS in Not the Only Target • Oct. 2013, Multiple Vulnerabilities in Apple Mac OS X Could Allow Remote Code Execution, http://msisac.cisecurity.org/advisories/2013/2013-100.cfm • Oct. 2013, Android security vulnerabilties, http://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/Google-Android.html • Nov. 2013, Ubuntu security notices, http://www.ubuntu.com/usn/ Computer Science and Engineering

4. Computer System Security Computer Science and Engineering

5. Prevent/detect/deter improper Disclosure of information Secrecy Prevent/detect/deter Improper modification of information Integrity Availability Prevent/detect/deter improper Denial of access to services Security Objectives Authentication Non-repudiation Computer Science and Engineering

6. Types of Threats • Errors of users • Natural/man-made/machine disasters • Dishonest insider • Disgruntled insider • Outsiders Computer Science and Engineering

7. Policy Organizational policy Information systems policy Computer Science and Engineering

8. Security Control Components • Security policy: specifies the authorized accesses of a system • Security mechanism: implements and enforces the policy • Principles of protection • Least privilege • Need to know Computer Science and Engineering

9. Operating Systems • What is an operating system? • What operating systems do? • Why do we need security in operating systems? • Unintended errors, flaws, bugs, etc. • Malicious activities • Readings: • Silberschatz, Galvin, Gagne: Operating Systems Concepts, Chapters 14 and 15 Computer Science and Engineering

10. Software Security • Develop software that is free of flaws • Software engineering – functional requirements • Software Development Life Cycle (SDLC) • Protect against malicious code • Reading: • G. McGraw, Software Security , http://www.cigital.com/papers/download/bsi1-swsec.pdf Computer Science and Engineering

11. What is a Secure Code? • Characteristics that contribute to security • Who defines the characteristics? • Assessment of security • What is the basis for the assessment? • IEEE Standard for Software Verification and Validation, 2005 • Bug, error, fault, … • US National Security Agency: System Security Engineering CMM (SSE CMM), http://www.sse-cmm.org/index.html Computer Science and Engineering CSCE 548 - Farkas 11

12. Software Security • NOT security software! • Engineering software so that it continues to function correctly under malicious attack • Functional requirements • Non-functional requirements (e.g., security) Computer Science and Engineering

13. Secure Software Development Best Practices External Review 3. Penetration Testing 1. Code Review (Tools) 6. Security Requirements 4. Risk-Based Security Tests 2. Risk Analysis 7. Security Operations 5. Abuse cases 2. Risk Analysis Requirement and Use cases Architecture and Design Test Plans Code Tests and Test Results Feedback from the Field Computer Science and Engineering

14. Security Functionality of OS Computer Science and Engineering

15. OS Security Functionalities • Identity and credential management • Access control • Information flow • Audit and integrity protection Computer Science and Engineering

16. Access Control • Protection Objects: • Memory • File • Directory of files • Applications • Hardware devices • System components • … Computer Science and Engineering

17. Access Control Requires: - Proper user identification - Information specifying the access rights is protected form modification Computer Science and Engineering

18. Identification and Authentication • Allows an entity (a user or a system) to prove its identity to another entity • Typically, the entity whose identity is verified reveals knowledge of some secret S to the verifier • Strong authentication: the entity reveals knowledge of S to the verifier without revealing S to the verifier Reading: An Introduction to Computer Security: The NIST Handbook, http://csrc.nist.gov/publications/nistpubs/800-12/handbook.pdf: Chapter 16, Identification and Authentication, pages 180-194 Computer Science and Engineering

19. User Authentication • What the user knows • Password, personal information • What the user possesses • Physical key, ticket, passport, token, smart card • What the user is (biometrics) • Fingerprints, voiceprint, signature dynamics Computer Science and Engineering

20. Closed vs. Open Systems Closed system Open System (minimum privilege) (maximum privilege) Access requ. Access requ. Allowed accesses Disallowed accesses Exists Rule? Exists Rule? yes no no yes Access permitted Access denied Access permitted Access denied Computer Science and Engineering

21. How to specify access control? Computer Science and Engineering

22. Access Control • Subject: active entity that requests access to an object - e.g., user or program • Object: passive entity accessed by a subject - e.g., record, relation, file • Access right (privileges): how a subject is allowed to access an object - e.g., subject s can read object o Computer Science and Engineering

23. Access Control Policies • Discretionary Access Control (DAC) • Mandatory Access Control (MAC) • Role-Based Access Control (RBAC) Computer Science and Engineering

24. Discretionary Access Control (DAC) • For each subject access right to the objects are defined • (subject, object, +/- access mode) • (Black, Grade-file, +read) • User based • Grant and Revoke • Problems: - Propagation of access rights - Revocation of propagated access rights Computer Science and Engineering

25. Access Matrix Model OBJECTS AND SUBJECTS File 1 File 2 S U B J E C T S Joe Sam Computer Science and Engineering

26. Implementation File 1 File 2 Joe:Read Joe:Read Joe:Write Sam:Read Joe:Own Sam:Write Sam:Own Access Control List (column) (ACL) Capability List (row) Joe: File 1/Read, File 1/Write, File 1/Own, File 2/Read Sam: File 2/Read, File 2/Write, File 2/Own Subject Access Object Joe Read File 1 Joe Write File 1 Joe Own File 1 Joe Read File 2 Sam Read File 2 Sam Write File 2 Sam Own File 2 Access Control Triples Computer Science and Engineering

27. Other Security Concerns Computer Science and Engineering

28. Trusted Operating System • Code has been rigorously developed and analyzed • Key characteristics: • Functional correctness • Enforcement of integrity • Limited privilege • Appropriate confidence level Computer Science and Engineering

29. Computer System Evaluation Standards • 1960s: US Department of Defense (DoD) risk of unsecured information systems • 1981: National Computer Security Center (NCSC) at the NSA • DoD Trusted Computer System Evaluation Criteria (TCSEC) == Orange Book • Security features and Assurances • Trusted Computing Base (TCB) security components of the system • 1996: Common Criteria Computer Science and Engineering

30. Orange Book Levels Highest Security • A1 Verified protection • B3 Security Domains • B2 Structured Protection • B1 labeled Security Protections • C2 Controlled Access Protection • C1 Discretionary Security Protection • D Minimal Protection No Security Computer Science and Engineering CSCE 522 - Farkas 30

31. Thank you! Computer Science and Engineering