cs5460 operating systems lecture 24 security cs 5460
play

CS5460: Operating Systems Lecture 24: Security CS 5460: Operating - PowerPoint PPT Presentation

CS5460: Operating Systems Lecture 24: Security CS 5460: Operating Systems Once upon a time, this patch was made to Linuxs wait4() system call: + if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) +


  1. CS5460: Operating Systems Lecture 24: Security CS 5460: Operating Systems

  2.  Once upon a time, this patch was made to Linux’s wait4() system call: + if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) � + retval = -EINVAL; �  The commit came from one of the most active kernel developers  What is its effect? CS 5460: Operating Systems

  3. What’s Computer Security All About?  Cryptography  Network security  Writing secure code  Secure hardware  Secure operating systems  Etc … CS 5460: Operating Systems Lecture 25

  4. Today  OS security basics  UNIX security  Multilevel security  Secure operating systems  Integrity and auditing CS 5460: Operating Systems

  5. High-Level Security Goals  Privacy / Confidentiality – Information only available to authorized users  Integrity – Information retains intended content and semantics  Availability – Information retains access and presence  There is tension between these goals  Real systems must make difficult choices between them

  6. How Do We Approach Security?  Devise a security policy – Implements a security model – Boils down to a collection of rules  Next, we try to follow the rules – It’s hard to write large programs that follow security rules – It’s hard to get humans to follow security rules  There are many things that can go wrong CS 5460: Operating Systems

  7. Users  UNIX user -> username -> uid – uid is the system’s real name for user – integer 0 ... 65536 (varies in some systems) – mapping is in /etc/passwd regehr:x:1000:1000:John Regehr,,,:/mnt/z:/bin/bash  More than one username may map to a uid – Desired for some system purposes (program tracking) – Problem for ordinary users (confused file ownership) – Security problem (hacker makes duplicate uid account)  Command to change uid temporarily: su

  8. Unix Groups  A user is in one or more groups  A group contains zero or more users – Groups are used to give better file access control – Defined by /etc/groups and network sharing software – ypcat group.byname – CS department has 961 groups – gid - integer system name for group (generally unique)  Listed for individual users with “groups”  Change group of file with “chgrp” – chgrp newgroup myfile

  9. Unix File Security  Each file has owner and group  Permissions set by owner setid – Read, write, execute - rwx rwx rwx – Owner, group, other – Represented by vector of ownr grp othr four octal values  Only owner, root can change permissions – This privilege cannot be delegated or shared  Setid bits – Discuss in a few slides

  10. UNIX Permissions Practice 16 lab3-1:~> ls –l drwx------+ 2 regehr csprof 2 Sep 8 11:02 Desktop drwx------+ 2 regehr csprof 6 Oct 3 21:23 bin -rw-------+ 1 regehr csprof 25524 Nov 24 11:54 blkdev.h -rw-r--r--+ 1 regehr csprof 63507 Sep 11 23:02 clang-113697.patch -rwxrwx---+ 1 regehr csprof 411 Oct 5 18:11 copy_sat_ops.pl CS 5460: Operating Systems

  11. SETUID and SETGID  Special mechanisms: temporarily use a uid or gid during the execution of a program  Part of mode bits – s in user x field - setuid – s in group x field - setgid  To be effective, both s and x must be set – chmod a+x myprog – chmod u+s myprog – chmod 4755 myprog  WARNING: It’s hard to use this correctly

  12. Handin on CADE  Directory listing for the “ handin ” backend: -rwsrwxr-x 1 root tty 24715 Nov 24 1999 rcvhandin  Now tell me how handin works – What happens when you run it? – How would you use handin to read another student’s files? CS 5460: Operating Systems

  13. Unix Summary  Good things – Some protection from most users – Flexible enough to make things possible  Main bad thing: it’s not very expressive – For example, can’t easily just let a single user mount a CDROM or add users to the system – Too tempting to use root privileges

  14. Multilevel Security  Users with different “ needs to know ” share a computer or network  If don’t need to know – shouldn’t even be able to determine if information exists  Should be able to filter functionality based on allowable information

  15. Military Security Model  Information is ranked: – Unclassified – Confidential – Secret – Top Secret  Least Privilege: Subject should have access to fewest objects needed for successful work – The system backup program may be allowed to bypass read restrictions on files, but it would not have the ability to modify files. – “ Need to Know ”

  16. Compartmentalization Information may belong to one or more compartments Compartments are used to enforce need-to- know.  Classification of Information: <rank; compartments>  Clearance: <rank; compartments> – an indication of a level of trust  A subject can access an object only if – The clearance level of the subject is at least as high as that of the information. – The subject has a need to know about all compartments for which the information is classified.

  17. Information Flow Models  Acts as an filter to control the transfer of information permitted by access to a particular object  Information flow analysis can assure that operating system modules that have access to sensitive data cannot leak that data to calling modules

  18. Bell-LaPadula Model  A formal description of the allowable paths of information flow in a secure system – Applies only to privacy (not availability or integrity) – Identifies paths that could lead to inappropriate disclosures – Is used as the basis for the design of systems that handle data of multiple levels – Includes both discretionary and mandatory access rules

  19. Bell-LaPadula Mandatory Controls  Fixed security classes for each subject and each object  Security classes ordered by a relation  Simple Security Property: – Subject may have read access only if object classified at same level or lower.  * - Property: – Subject may have write access only if all objects read are at same level or higher than object to be written.  Summary: “ No read up, no write down ”  Trusted subjects may violate the *-property

  20. Picture: Confidentiality Read below, write above Read above, write below Proprietary Proprietary S S Public Public

  21. Biba Model  Concerned with integrity rather than privacy  Defines integrity levels much like sensitivity levels – Fixed integrity classes for each subject and each object – Ordered integrity classes

  22. Biba Properties  Simple Integrity Property: – Subject can modify object only if integrity class at least as high as the object. (untrusted subjects reduce integrity class when writing)  * - Property: – Subjects may have write access only if the integrity of objects they are reading is at least as high as the object to be written. (untrusted sources reduce integrity of results)

  23. Integrity Preservation  A high integrity file is one whose contents are created by high-integrity processes. – high-integrity file cannot be contaminated by information from low-integrity processes. – high-integrity process cannot be subverted by low integrity processes or data.  The integrity class label on a file guarantees that the contents came only from sources of at least that degree of integrity.

  24. Picture: Integrity Read above, write below Read below, write above Proprietary Proprietary S S Public Public

  25. Problem: Models are contradictory  Bell-LaPadula Confidentiality – Read down, write up  Biba Integrity – Read up, write down  Want both confidentiality and integrity – Only way to satisfy both models is only allow read and write at same classification In reality: Bell-LaPadula used more than Biba model Example: Common Criteria

  26. Sample Features of a Secure OS  Mandatory access control – MAC not under user control  Object reuse protection – Write over old data when file space is allocated  Complete mediation – Prevent any access that circumvents monitor  Audit support  Intrusion detection – Anomaly detection » Learn normal activity, Report abnormal actions – Attack detection » Recognize patterns associated with known attacks

  27. Basic Design Principles  Least privilege - fewest possible privileges for user  Economy of mechanism - small, simple, straight forward  Open design  Complete mediation - check every access  Permission based - default is denial of access  Separation of privilege - no single super user  Least common mechanism - avoid shared objects  Easy to use

  28. Monitor Model  General idea: – Take user's request – Consult access control information – Allow or disallow request  Advantages – Easy to implement – Easy to understand  Disadvantages – Bottleneck in system – Controls only direct accesses (not inferences)

  29. Security Kernel  Responsible for implementing the security mechanisms of the entire operating system.  Provides the security interfaces among the hardware, the operating system, and the other parts of the computing system.  Implementation of a security kernel: – May degrade system performance (one more layer). – May be large. – No guarantees.  Designing a security kernel is hard – Linux, MacOS, and Windows do not have one – Virtual machine managers act as security kernels

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend