This document discusses security aspects in distributed operating systems. It covers authentication methods like symmetric cryptography and public key cryptography. It also discusses authorization mechanisms like access control matrices, lists and capabilities. The document proposes a design for distributed authentication using public key Kerberos and distributed authorization using trust management systems. It concludes that current security in distributed OS still relies on traditional centralized mechanisms and that alternatives like trust management systems are still immature.

1. 02/01/1502/01/15 11
Security Aspects
in
Distributed Operating Systems
CPSC 551 – Distributed Operating Systems
Presented by:
Cynthia Michele Vincent

2. 02/01/15 2
Overview
 Introduction
 Authentication in OS & Distributed OS
 Authorization in OS & Distributed OS
 Authorization in Amoeba
 Suggested Design using
 Distributed Authentication
 Distributed Authorization
 Conclusion

3. 02/01/15 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. 02/01/15 4
Authentication
 Are you really who you say you are?
 Authentication in Centralized Systems
 Authentication in Distributed Systems
 EavesdroppingEavesdropping
• Symmetric Cryptography, Public-Key Cryptography
 TrustTrust
• Certificate Authorities (CA), KDC
 Multiple Password ManagementMultiple Password Management
• Kerberos, X.509
 ReplayReplay
• Sequence numbers, Timestamp, Nonce

5. 02/01/15 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. 02/01/15 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. 02/01/15 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
Source: Stallings
1
2

8. 02/01/15 8
Kerberos
 To deal with multiple password management
 Provides access transparency
Source: Stallings

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

10. 02/01/15 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, CapabilityMechanisms are the same – ACLs, Capability
 Issues related to mechanismsIssues related to mechanisms
• Centralized
• Delegation
• Revocation
• Flexibility
 Solution that addresses those issuesSolution that addresses those issues
• Trust management systems

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

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

13. 02/01/15 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. 02/01/15 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. 02/01/15 15
An Example: Amoeba
 Capability-Based System
 Generation of a restricted capability from an
owner capability
Source: Mullender
Source: Tanenbaum

16. 02/01/15 16
Security Policies
 Discretionary
 Mandatory
 Identity-Based
 Role-Based
 Policy-Based
 Content-Dependent
 Context-Based
 View-Based
Role-Role-
BasedBased
AccessAccess
ControlControl
RoleRole
AssignmentAssignment
Role
Action
Resource
Roles/Groups table Policy
Role-Based Access Control
LoginLogin
(ID, password)(ID, password)
ID
Password File
Identity-Identity-
BasedBased
AccessAccess
ControlControl
LoginLogin
(ID, password)(ID, password)
UserID,
Password
UserID
Action
Resource
Password File Policy
Identity-Based Access Control
Source: Hertzberg

17. 02/01/15 17
Role-Based Access Control
Advantages
 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. 02/01/15 18
Role-Based Access Control
Disadvantages
 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. 02/01/15 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. 02/01/15 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.
CSU
CSUF CSUDH
A
B C

21. 02/01/15 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. 02/01/15 22
 Systematic approach for specifying what’s
allowed & for managing
 Security policiesSecurity policies
 User credentialsUser credentials
 Trust relationshipsTrust relationships
 Composed of languages that
 Describe actionsDescribe actions
 Specifies policiesSpecifies policies
 Specifies credentialsSpecifies credentials
 Consists of mechanisms for
 Identifying principalsIdentifying principals
 Checking complianceChecking compliance
Trust Management Systems (Cont’d)

23. 02/01/15 23
Suggested Design
Distributed 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. 02/01/15 24
 Trust management systems
Suggested Design
Distributed Authorization
Credential
System
Local
Policy db
Application
Signed
Credentials
Local
Policies
Key and
Action
Description
Response
Compliance
Checker
(Interpreter)
Credentials
Action
Requests
Trust
Boundary
y = tms(r, c, p)

25. 02/01/15 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. 02/01/15 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