Le Lecture 15 15 Access Control 1 Recall: Secu curity Service - - PowerPoint PPT Presentation

▶
le lecture 15 15
SMART_READER_LITE
LIVE PREVIEW

Le Lecture 15 15 Access Control 1 Recall: Secu curity Service - - PowerPoint PPT Presentation

Dec 29, 2022 327 likes •662 views

Le Lecture 15 15 Access Control 1 Recall: Secu curity Service ces Confidentiality: to assure information privacy and secrecy Authentication: to assert who created or sent data Integrity: to show that data has not been altered

slide-1
SLIDE 1

Le Lecture 15 15

1

Access Control

slide-2
SLIDE 2

Recall: Secu curity Service ces

  • Confidentiality: to assure information privacy and secrecy
  • Authentication: to assert who created or sent data
  • Integrity: to show that data has not been altered
  • Access Control: to prevent misuse of resources
  • Availability: to offer access to resources, permanence, non-

erasure Examples of attacks on Availability: – Denial of Service (DoS) Attacks

  • e.g., against a name server

– Malware that deletes or encrypts files

2

slide-3
SLIDE 3

Acce ccess Control (AC)

  • A “language” for expressing access control policies:

who can access what, how and when …

  • Enforcement of access control
  • Identify all resources (objects) and their granularity
  • Identify all potential users (subjects)
  • Specify rules for subject/object interaction
  • Guard them in real time

3

slide-4
SLIDE 4

Mo Mode del a and T nd Term rmino nology

  • Subjects: users or processes
  • Objects: resources (files, memory, printers,

routers, plotters, disks, processes, etc., etc.,...)

4

slide-5
SLIDE 5

Focu cus of Acce ccess Control

  • What a subject is allowed to do
  • What may be done with an object

5

slide-6
SLIDE 6

Acce ccess Modes

6

  • “Look” at an object, e.g.:
  • Read file
  • Check printer queue
  • Print remote screen
  • Query database
  • etc., etc.
  • “Change” an object, e.g.:
  • Write/append/erase file
  • Print or fax
  • Display on screen
  • etc., etc.
slide-7
SLIDE 7

Acce ccess Rights

execute, read, append, and write

7

Observe Alter Execute Append Read Write X X X X

slide-8
SLIDE 8

UN UNIX/Linux nux/*x Ope perating ng Systems

  • execute: execute (program) file, search directory
  • read: read from file, list directory
  • write: write (re-write or append) file, create or

rename file in directory

8

slide-9
SLIDE 9

Ex Exampl ple: Windo ndows NT/2000 (NTFS)

  • execute
  • read
  • write
  • delete
  • change permission
  • change ownership

9

slide-10
SLIDE 10

AC AC Types

Who is in charge of setting AC policy?

  • Discretionary: resource owner
  • Mandatory: system-wide policy

10

slide-11
SLIDE 11

Acce ccess Control Struct ctures

i. Access Control Matrix ii. Capabilities

  • iii. Access Control Lists

11

slide-12
SLIDE 12

Acce ccess Control Matrix

12

Alice Bob

Bill.doc

{read,write} {execute} {execute} {execute,read} {execute,read,write}

Edit.exe Fun.com Subject Object

{0}

slide-13
SLIDE 13

Acce ccess Control Lists 1/2

Keep access rights to an object with that object:

§

ACL for bill.doc:

§

Bob: read, write

§

ACL for edit.exe:

§

Alice: execute;

§

Bob: execute

§

ACL for fun.com:

§

Alice: execute, read;

§

Bill: execute, read, write

13

  • As many ACLs as there are objects
  • Each ACL either signed or stored in protected place
  • Hard to manage
slide-14
SLIDE 14

Acce ccess Control Lists 2/2

  • Managing access rights can be difficult
  • Groups can be helpful …
  • Groups simplify definition of access control

policies

14

slide-15
SLIDE 15

Acce ccess Control Lists

15

S1 S2 S3 O4 O3 O2 O1 G1 O5

X

slide-16
SLIDE 16

Ca Capabiliti ties es 1/ 1/2

  • Capabilities are associated with discretionary

access control

  • Reason: difficult to get full view of who has

permission to access an object

  • Very difficult to revoke a capability

(owners/objects have to keep track of all issued capabilities)

16

  • As many capabilities as there are subject/object pairs
  • Each capability either signed or otherwise protected
  • Hard to revoke in a distributed setting
slide-17
SLIDE 17

Ca Capabiliti ties es 2/ 2/2

Keep access rights with the subject:

  • Alice's capabilities:
  • [edit.exe:execute];
  • [fun.com:execute,read]
  • Bob's capabilities:
  • [bill.doc:read,write]
  • [edit.exe:execute]
  • [fun.com:execute,read,write]

17

slide-18
SLIDE 18

In In Su Summa mmary

  • Centralized Systems:
  • ACLs are better
  • Distributed Systems:
  • Capabilities are better

18

slide-19
SLIDE 19

19

Example: Android Security/Permissions

slide-20
SLIDE 20

Android Security Model

  • Application-level permissions model
  • Controls access to app components
  • Controls access to system resources
  • Specified by the app writers and seen by the users
  • Kernel-level sandboxing and isolation
  • Isolate apps from each other and the system
  • Prevent bypass of application-level controls
  • Relies on Linux Discretionary Access Control (DAC)
  • Normally invisible to the users and app writers

20

slide-21
SLIDE 21

Discretionary Access Control (DAC)

  • Typical form of access control in Linux
  • Access to data is entirely at the discretion of

the owner/creator of the data

  • Some processes (e.g., uid 0) can override

and some objects (e.g., sockets) are unchecked

  • Based on user & group identity
  • Limited granularity, coarse-grained privilege

21

slide-22
SLIDE 22

Android and DAC

  • Restrict use of system facilities by apps
  • e.g., bluetooth, network, storage access
  • requires kernel modifications, “special”

group IDs

  • Isolate apps from each other
  • unique user and group ID per installed app
  • assigned to app processes and files
  • Hardcoded, scattered “policy”

22

slide-23
SLIDE 23

Security Enhanced (SE)Linux : What is it?

  • Mandatory Access Control (MAC) for Linux
  • Defines and enforces a system-wide security policy
  • Over all processes, objects, and operations
  • Based on security labels
  • Can confine flawed and malicious applications
  • Even ones that run as “root”/uid 0
  • Can prevent privilege escalation

23

slide-24
SLIDE 24

How Can SELinux Help Android?

  • Confine privileged daemons
  • Protect them from misuse
  • Limit the damage that can be done via them
  • Sandbox and isolate apps
  • Strongly separate apps from each other and

from the system

  • Prevent privilege escalation by apps
  • Provide centralized, analyzable policy

24

slide-25
SLIDE 25

Security Enhanced (SE)Linux in Android

25

More details at: http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf

slide-26
SLIDE 26

26

ROLE BASED ACCESS CONTROL (RBAC)

slide-27
SLIDE 27

27

RBAC Basics

  • Users are associated with roles
  • Roles are associated with permissions
  • A user has permission only if s/he has a

role associated with that permission

slide-28
SLIDE 28

28

Example: The Three Musketeers (User/Permission Association)

palace weapons uniform

Athos Porthos Aramis

slide-29
SLIDE 29

29

Example: The Three Musketeers (RBAC)

Musketeer

palace weapons uniform

Athos Porthos Aramis

palace weapons uniform

Athos Porthos Aramis

slide-30
SLIDE 30

30

Musketeer

palace weapons uniform

Athos Porthos Aramis

palace weapons uniform

Athos Porthos Aramis

Example: The Three Musketeers (RBAC)

slide-31
SLIDE 31

31

Musketeer

palace weapons uniform

Athos Porthos Aramis

palace weapons uniform

Athos Porthos Aramis

Here RBAC doesn’t work …

Example: The Three Musketeers (RBAC)

slide-32
SLIDE 32

32

Example: (D’Artagnon becomes a Musketeer)

Musketeer

palace weapons uniform

D'Artagnan

palace weapons uniform

D'Artagnan