1 / 26

Security Aspects in Distributed Operating Systems

This presentation discusses the authentication and authorization processes in operating systems and distributed operating systems, as well as the use of distributed authentication and authorization in Amoeba. It also covers topics such as symmetric cryptography, public-key cryptography, certificate authorities, and access control mechanisms like access control matrices, access control lists, and capabilities. The presentation concludes with an exploration of different security policies, including discretionary, mandatory, identity-based, role-based, policy-based, content-dependent, context-based, and view-based policies.

jamesdmartin
Download Presentation

Security Aspects in Distributed Operating Systems

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security AspectsinDistributed Operating Systems CPSC 551 – Distributed Operating Systems Presented by: Cynthia Michele Vincent

  2. Introduction Authentication in OS & Distributed OS Authorization in OS & Distributed OS Authorization in Amoeba Suggested Design using Distributed Authentication Distributed Authorization Conclusion Overview

  3. Introduction • Why security? • Necessary to avoid unintentional or malicious attempts that affects the integrity of the system • Difference between security in OS and security in Distributed OS • One of the functions of OS • Authenticate and authorize users • One of the functions of Distributed OS • Authenticate and authorize users • To handle security across multiple computers, global tables need to be • Created • Maintained • Accessed

  4. Authentication • Are you really who you say you are? • Authentication in Centralized Systems • Authentication in Distributed Systems • Eavesdropping • Symmetric Cryptography, Public-Key Cryptography • Trust • Certificate Authorities (CA), KDC • Multiple Password Management • Kerberos, X.509 • Replay • Sequence numbers, Timestamp, Nonce

  5. Symmetric Cryptography • To deal with eavesdropping • Shared common key to encrypt and decrypt • Requires a key distribution center (KDC) • Issue is secure key distribution Source: Stallings

  6. Public Key Cryptography • To deal with eavesdropping • No shared common key: public key, private key • Addresses key distribution with no KDC • Addresses digital signatures Source: Stallings

  7. Certificate Authorities • To deal with trust • A certificate binds identity to public key • Contents signed by a trusted 3rd party • Different trust models / Hierarchy of Trust 1 2 Source: Stallings

  8. Kerberos • To deal with multiple password management • Provides access transparency Source: Stallings

  9. Nonce • To deal with replay • Timestamp, counter, random number • Transformation of a nonce performs an authentication function Source: Stallings 3 4 5

  10. Authorization • Granting access rights / verifying access rights • Authorization in Centralized Systems • Access Control Matrix • Access Control List (ACL) • Capability • Security Policies • Authorization in Distributed Systems • Mechanisms are the same – ACLs, Capability • Issues related to mechanisms • Centralized • Delegation • Revocation • Flexibility • Solution that addresses those issues • Trust management systems

  11. Reference Monitor • General model of controlling access to objects • A program that records which subject may do what and decides Access Control Database What’s in this db? Subjects Objects Reference Monitor within OS Authorized Request Request for operation Source: Raytheon Systems Audit Logs Subjects: Processes, Users, Applications Objects: records, blocks, pages, segments, files, directories, directory trees, programs, bits, bytes, words, fields, video displays, keyboards, clocks, printers

  12. Access Control Matrix • Mechanism for implementing access control Objects File 1 File 2 File 3 File 4 Subjects Person 1 RWE Person 2 R E W R Person 3 E Person 4 Access Rights: R = read; W = write; E = execute

  13. Access Control List • The matrix is distributed column-wise • Each object maintains a list of the access rights of subjects • Empty entries are left out • Must be scanned each time any subject accesses an object • Revocation is trivial • Delegation can’t be done Source: Tanenbaum

  14. Capability • Rows of access matrix corresponding to each subject • Give each subject a list of capabilities it has for each object • No capability = No access rights • Like a ticket but must be unforgeable • Revocation is infeasible • Delegation is trivial • High-level administrative authorities can certify lower-level authorities Source: Tanenbaum

  15. An Example: Amoeba • Capability-Based System • Generation of a restricted capability from an owner capability Source: Mullender Source: Tanenbaum

  16. Policy Policy Password File Password File Roles/Groups table UserID, Password Login (ID, password) Login (ID, password) Role Assignment UserID ID Role Identity- Based Access Control Role- Based Access Control Action Action Resource Resource Identity-Based Access Control Role-Based Access Control Security Policies • Discretionary • Mandatory • Identity-Based • Role-Based • Policy-Based • Content-Dependent • Context-Based • View-Based Source: Hertzberg

  17. Role-Based Access ControlAdvantages • Flexibility • Granularity of system privilege management • Useful in applications with • A large number of users with • Overlapping user requirements, and • When there is a large number of objects • System privileges are grouped according to their logical association to form roles • Administration of privileges is easier • 2K

  18. Role-Based Access ControlDisadvantages • RBAC was developed for access control in a single organization • A role name is an atomic string • Complexity • Analysis associated with determining system privileges • Understanding the implications of their assignment • Reduce it by decomposing roles into sub-roles

  19. Issues • Granularity and labor-intensive management • Flexibility but complexity • If mechanisms are not expressible and flexible • Policy elements must be hard-coded into applications • Changes in security will require • Reconfiguration • Rebuilding • Rewriting of applications • Different applications needs different access-granting/restricting policies • Must adapt to changing environment to deal with changing threats • More complex security policies needed in distributed operating systems

  20. Issues (Cont’d) • If mechanisms enforce uniform and implicit policies and trust relations • How can we handle those entities wishing to have a different trust model? • If mechanisms have high level admin authorities that cannot directly specify overall security policy • There would be inconsistencies among locally specified sub-policies. A CSU C B CSUF CSUDH

  21. Trust Management Systems • Developed as an answer to the inadequacy of traditional authorization mechanisms • Handles other weak points of ACLs and Capability • Revocation • Delegation • A common language for policies, credentials and trust relationships • Handles security completely and consistently • Handles security in a transparent manner

  22. Trust Management Systems (Cont’d) • Systematic approach for specifying what’s allowed & for managing • Security policies • User credentials • Trust relationships • Composed of languages that • Describe actions • Specifies policies • Specifies credentials • Consists of mechanisms for • Identifying principals • Checking compliance

  23. Suggested DesignDistributed Authentication • Public Key-Based Kerberos • Requires public key operations each time a service ticket is required • Operations are distributed among the users and the services rather than concentrating them at the KDC • Fully distributed authentication between the users and the services using public key cryptography means • No need to maintain symmetric keys with the KDC • No more KDC to be compromised • Only the CA remains the trusted intermediary

  24. Suggested DesignDistributed Authorization • Trust management systems Action Requests Credentials Key and Action Description Signed Credentials Credential System Compliance Checker (Interpreter) Application Response Local Policies Local Policy db y = tms(r, c, p) Trust Boundary

  25. Summary • Differences in • Authentication in OS and distributed OS • Authorization in OS and distributed OS • Concerns in authentication in distributed OS • Answers (encryption, etc.) • Issues in security policies & mechanisms used for authorization in distributed OS • Suggested design • Distributed authentication – Public-Key Kerberos • Distributed authorization – Trust Management Systems

  26. Conclusion • A secure distributed OS design depends on • Ability to protect the flow of information through the system • Fine-grain access control • Decentralized solutions • Where are we? • Still using the traditional mechanisms • Why haven’t we moved? • Lack of alternatives suited for distributed OS • Infancy -- Trust management systems and other language/compiler-based protection systems

More Related