computer system security cse 5339 7339 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Computer System Security CSE 5339/7339 PowerPoint Presentation
Download Presentation
Computer System Security CSE 5339/7339

Loading in 2 Seconds...

play fullscreen
1 / 27

Computer System Security CSE 5339/7339 - PowerPoint PPT Presentation


  • 141 Views
  • Uploaded on

Computer System Security CSE 5339/7339. Session 19 October 26, 2004. Contents. A4  in A5  out Trusted Operating Systems Angela’s presentation. Trusted OS Design. OS is a complex system  difficult to design

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Computer System Security CSE 5339/7339


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. Computer System SecurityCSE 5339/7339 Session 19 October 26, 2004

    2. Contents • A4  in • A5  out • Trusted Operating Systems • Angela’s presentation

    3. Trusted OS Design • OS is a complex system  difficult to design • Adding the responsibility of security enforcement makes it even more difficult • OS controls interactions between subjects and objects • Clear mapping from security requirements to the design • Design must be checked using formal reviews or simulation • Requirements  design  testing

    4. Security Design Principles • Least privilege – users, programs, fewest privilege possible • Economy of mechanism – small, simple, straight forward • Open design – extensive public scrutiny • Complete mediation – every attempt must be checked • Permission based – denial of access is the default • Separation of privilege – more than one condition • Least common mechanism – the risk of sharing • Ease of use – unlikely to be avoided

    5. OS Functions users User interface Synchronization Concurrency control Deadlock management Communication Accounting OS Services Resource allocation Data CPU Memory I/O devices Tables Libraries

    6. Security features in ordinary OS • Authentication of users – password comparison • Protection of memory – user space, paging, segmentations • File and I/O device access control – access control matrix • Allocation & access control to general objects – table lookup • Enforcement of sharing – integrity, consistency • Fair service – no starvation • Interprocess communication & synchronization – table lookup • Protection of OS protection data – encryption, hardware control, isolation

    7. Security features of Trusted OS • Identification and Authentication • Mandatory and Discretionary Access Control (MAC & DAC) • Object reuse protection • Complete mediation – all accesses are checked • Trusted path • Accountability and Audit – security log • Audit log reduction • Intrusion detection – patterns of normal system usages, anomalies

    8. Kernel – OS part that performs lowest level functions User tasks OS OS Kernel Hardware

    9. Security Kernel – responsible for enforcing security mechanisms of the entire OS • Coverage – ensure that every access is checked • Separation – security mechanisms are isolated from the rest of OS and from user space  easier to protect • Unity – allsecurity mechanisms are performed by a single set of code  easier to trace problems • Modifiability – security mechanism changes are easier to make and test • Compactness – relatively small • Verifiability – formal methods , all situations are covered

    10. Reference Monitor – the portion of a security kernel that controls accesses to objects O O O Gate • Collection of access controls for • Devices • Files • Memory • Interprocess communication • Other objects • It must be • Always invoked when any object is accessed • Small enough – analysis, testing • Tamperproof S S S

    11. Trusted Computing Base (TCB) – everything in the trusted OS necessary to enforce security policy System element on which security enforcement depends: • Hardware – processors, memory, registers, and I/O devices • Processes – separate and protect security-critical processes • Primitive files – security access control database, identification/authentication data • Protected memory – reference monitor can be protected against tampering • Interprocess communication – for example: reference monitor can invoke and pass data securely to audit routine

    12. Applications Utilities User request interpreter … Segmentation, paging, memory management TCB and Non-TCB Code Non-TCB Primitive I/O Basic Operations Clocks, timing Interrupt handling Hardware:registers memory Capabilities TCB

    13. TCB monitors 4 basic interactions: • Process activation • Execution domain switching • Memory Protection • I/O operation

    14. User tasks Combined Security Kernel / OS System OS Kernel: - HW interactions - Access control OS OS Kernel Hardware OS: • Resource allocation • Sharing • Access control • Authentication functions Security activity

    15. User tasks Separate Security Kernel Security Kernel: • Access control • Authentication functions OS Security Kernel Hardware OS: • Resource allocation • Sharing • Hardware interactions

    16. Separation: • Physical Separation • Temporal Separation • Cryptographic Separation • Logical separation (isolation)

    17. Virtualization: • Illusion • The OS emulates or simulates a collection of a computer system’s resources. • Virtual Machine: Collection of real or simulated hardware facilities – processor, memory, I/O devices

    18. IBM MVS/ESA • Paging System • Virtualization is used to provide logical separation that gives the user the impression of physical separation. • Each user feels that he/she has a separate machine • Each user’s virtual memory space cab be as large as the total addressable space.

    19. Virtual machine Virtual Machine User 1 Virtual Machine User 2 Virtual Machine User 3 Real OS Real System Resources

    20. User processes Layered OS Compilers, database Utility functions OS File system, device allocation Scheduling, sharing, MM Synchronization, allocation OS kernel Security functions Security kernel Hardware

    21. Provably Secure Operating System (PSOS) • 16 level Layered structure (see table – page 272) • Each layer uses the services of the layers below it, and provides certain level of functionality to the layers above it. • Peel off each layer and still have a logically complete system with less functionality

    22. Conventionally vs. Hierarchically Designed Systems

    23. Assurance • Testing – based on the actual product being evaluated, not on abstraction • Verification – each of the system’s functions works correctly • Validation – the developer is building the right product (according to the specification)

    24. Testing • Can demonstrate the existence of a problem, but passing tests does not imply the absence of problems • Hard to achieve adequate test coverage within reasonable time – inputs & internal states • Observable effects versus internal structure • real-time systems – hard to keep track of all states • Penetrating Testing – tiger team analysis, ethical hacking Team of experts in the design of OS tries to crack the system

    25. Formal verification • The most rigorous method • Rules of mathematical logic to demonstrate that a system has certain security property • Proving a Theorem • Time consuming – complex process • Simple example

    26. Example – Finding the minimum value Flow chart – page 278 Assertions P: n > 0 Q: n > 0 and 1  i  n and min  A[1] R: n > 0 and S: n > 0 and 1  i  n and i = n + 1 and for all j 1  j  i -1 for all j 1  j  i -1 min  A[j] min  A[j]

    27. Validation • Requirements checking – system does things it should do(in security, system does not do things it is not supposed to do) • Design and code reviews – traceability from each requirement to design and code components • System testing – data expected from reading the requirement document can be confirmed in the actual running of the systems