dos_security_final

02/01/1502/01/15 11

Security Aspectsin

Distributed Operating Systems

CPSC 551 – Distributed Operating Systems

Presented by:

Cynthia Michele Vincent

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

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

02/01/15 4

Authentication

Are you really who you say you are? Authentication in Centralized Systems Authentication in Distributed Systems

Eavesdropping Eavesdropping • Symmetric Cryptography, Public-Key Cryptography

TrustTrust• Certificate Authorities (CA), KDC

Multiple Password ManagementMultiple Password Management• Kerberos, X.509

ReplayReplay• Sequence numbers, Timestamp, Nonce

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

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

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

02/01/15 8

Kerberos

To deal with multiple password management Provides access transparency

Source: Stallings

02/01/15 9

Nonce

To deal with replay Timestamp, counter, random number Transformation of a nonce performs an

authentication functionSource: Stallings

3

4

5

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

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 SystemsAudit Logs

Objects

Access Control

Database

Request for operation

Reference

Monitor within

OS

AuthorizedRequest

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

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

ObjectsSubjects

RWE

R E W

Access Rights: R = read; W = write; E = execute

R

E

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

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 authoritiesSource: Tanenbaum

02/01/15 15

An Example: Amoeba

Capability-Based System Generation of a restricted capability from an owner

capabilitySource: Mullender

Source: Tanenbaum

02/01/15 16

Security Policies

Discretionary Mandatory

Identity-Based Role-Based Policy-Based Content-Dependent Context-Based View-Based

Role-Role-BasedBasedAccessAccessControlControl

RoleRoleAssignmentAssignment

Role

Action

Resource

Roles/Groups table Policy

Role-Based Access Control

LoginLogin(ID, password)(ID, password)

ID

Password File

Identity-Identity-BasedBasedAccessAccessControlControl

LoginLogin(ID, password)(ID, password)

UserID,Password

UserID

Action

Resource

Password File Policy

Identity-Based Access Control

Source: Hertzberg

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

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

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

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

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

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)

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

02/01/15 24

Trust management systems

Suggested DesignDistributed Authorization

CredentialSystem

LocalPolicy db

Application

SignedCredentials

LocalPolicies

Key andAction

Description

Response

ComplianceChecker

(Interpreter)

CredentialsAction

Requests

TrustBoundary

y = tms(r, c, p)

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

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