CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

55
CIT 380: Securing Computer Systems Slide #1 CIT 380: Securing Computer Systems Access Control

description

CIT 380: Securing Computer SystemsSlide #3 Why study Access Control? Center of gravity of computer security –Why do we authenticate users? –What security features do OSes provide? –What’s the purpose of cryptography? –Access Control is pervasive. Access Control is where Computer Science meets Security Engineering. –We’ll start with theory (computer science) –Then examine implementations (engineering)

Transcript of CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

Page 1: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #1

CIT 380: Securing Computer Systems

Access Control

Page 2: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #2

Access Control• What is Access Control?• Access Control Matrix Model

– Protection State Transitions– Special Rights– Principle of Attenuation of Privilege

• Groups and Roles• Implementation of the Access Control Matrix

– Access Control Lists: by column (object).– Capabilities: by row (subject).– UNIX, Windows NT, and SQL ACLs.

• Hardware Protection

Page 3: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #3

Why study Access Control?• Center of gravity of computer security

– Why do we authenticate users?– What security features do OSes provide?– What’s the purpose of cryptography?– Access Control is pervasive.

• Access Control is where Computer Science meets Security Engineering.– We’ll start with theory (computer science)– Then examine implementations (engineering)

Page 4: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #4

Access Control is Pervasive

Application

Middleware

Operating System

Hardware

Page 5: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #5

Access Control is Pervasive1. Application

• Complex, custom security policy.• Ex: Amazon account: wish list, reviews, CC

2. Middleware• Database, system libraries, 3rd party software• Ex: Credit card authorization center

3. Operating System• File ACLs, IPC

4. Hardware• Memory management, hardware device access.

Page 6: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #6

Access Control Matrix• Precisely describes protection state of system.

• Sets of system states:– P: Set of all possible states.– Q: Set of allowed states, according to security policy.– P-Q: Set of disallowed states.

• ACM describes the set of states Q.

PQ

Page 7: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #7

Access Control Matrix• As system changes, state changes.

– State transitions.– Only concerned with protection state.

• ACM must be enforced by a mechanism that limits state transitions to those that go from one element of Q to another.

Page 8: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #8

ACM Descriptionobjects (entities)

subj

ects

s1

s2

sn

o1 … om s1 … sn

• Objects O = { o1,…,om }– All protected entities.

• Subjects S = { s1,…,sn }– Active entities, S

• Rights R = { r1,…,rk }

• Entries A[si, oj] R

• A[si, oj] = { rx, …, ry } means subject si has rights rx, …, ry over object oj

Page 9: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #9

Example: File/Process• Processes p, q• Files f, g• Rights r, w, x, a, o

f g p qp rwo r rwxo wq a ro r rwxo

Page 10: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #10

Copy Right• Allows possessor to give rights to another• Often attached to a right, so only applies to

that right– r is read right that cannot be copied– rc is read right that can be copied

• Is copy flag copied when giving r rights?– Depends on model, instantiation of model

Page 11: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #11

Ownership Right Usually allows possessor to change entries

in ACM column– So owner of object can add, delete rights for

others– May depend on what system allows

• Can’t give rights to specific (set of) users• Can’t pass copy flag to specific (set of) users

Page 12: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #12

Attenuation of Privilege Principle: Subject may not give rights it

does not possess to another.– Restricts addition of rights within a system– Usually ignored for owner

• Why? Owner gives herself rights, gives them to others, deletes her rights.

Page 13: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #13

How can we implement the ACM?Problem: scale

– Thousands of subjects.– Millions of objects.– Yet most entries are blank or default.

Solutions– Group subjects together as a single entities

• Groups and Roles– Implement by row: Capabilities– Implement by column: Access Control Lists

Page 14: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #14

Groups and Roles• Collect subjects together to express:

– Need to share objects.– Security categories (e.g., admin, faculty,

student, guest)• role: group that ties membership to function• Problem: loss of granularity.

Page 15: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #15

Capabilities• Implement ACM by row.• Access Control associated with subject.• Example: UNIX file descriptors

– System checks ACL on file open, returns fd.– Process subsequently uses fd to read and write file. – If ACL changes, process still has access via fd.

User ls homedir rootdir

james rx rw r

Page 16: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #16

Capability Questions1. How to prevent user from modifying

capabilities?2. How to prevent user from copying

capabilities?3. How to revoke rights to an object?

Page 17: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #17

How to prevent user from modifying?

Memory protection– Capabilities are readable, but not writable.

Indirection– Capability is pointer to per-process table whose

access control prevents user from touching.

Cryptography– Cryptographically secure checksum associated

with capability and checked before usage.

Page 18: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #18

How to prevent user from copying?• Copying capabilities allows users to grant

rights to others.• Solution:

– Use indirection or cryptographic techniques from prev slide to prevent direct access.

– Add copy flag to capability, as a specific right given to copy capabilities in order to give rights to other users.

Page 19: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #19

How to revoke rights to an object?• Direct solution

– Check capabilities of every process.– Remove those that grant access to object.– Computationally expensive.

• Alternative solution– Create a global object table.– Capabilities reference objects indirectly via

their entries in the global object table.– Invalidate entry in global object table to revoke.

Page 20: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #20

Access Control Lists (ACLs)• Implement ACM by column.• Access control by object.• Example: UNIX ACLs

– Short “rwx” user/group/other.– Long POSIX ACLs.

User audit data

root rw

james r

joe

Page 21: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #21

ACL Questions1. Which subjects can modify an object’s

ACL?2. Do ACLs apply to privileged users?3. Do ACLs support groups and wildcards?4. How are ACL conflicts resolved?5. What are default permissions?6. How can a subject’s rights be revoked?

Page 22: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #22

Which subjects can modify an ACL?• Create an own right for an ACL.

– Only subjects with own right can modify ACL.• Creating an object also creates object’s ACL.

– Usually creator given own right at this time.– Other default rights may be set at creation too.

• Some systems allow anyone with access to object to modify ACL.– What are the security implications of sharing

access to a file on such a system?

Page 23: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #23

Do ACLs apply to privileged users?• Many systems have privileged users.

– UNIX: root.– Windows NT: administrator.

• Should ACLs apply to privileged users?– Need read access to all objects for backups.– What security problems are produced by

ignoring ACLs for privileged users?

Page 24: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #24

How are ACL conflicts resolved?What happens when multiple ACL entries give different permissions to same subject?– First entry wins.– Last entry wins.– Deny wins over allow.

Page 25: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #25

What are the default permissions?• Interaction of ACLs with base permissions.

– POSIX ACLs modify UNIX base permissions.• How are default ACLs determined?

– Subject• Subject sets default permissions, like UNIX umask.

– Inheritance• Objects in hierarchical system inherit ACLs of

parent object.• Subjects inherit sets of default permissions from

their parent subjects.

Page 26: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #26

How are rights revoked?Removal of subject’s rights to object.

– Delete entries for subject from ACL.– If ownership doesn’t control granting rights,

matters can be complex:• If A has granted rights to B, what should happen to

B’s rights if you remove A’s rights?

Removal of subject’s rights to all objects.– Very expensive (millions of objects.)– Most systems don’t support.– Why isn’t disabling subject’s account sufficient?

Page 27: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #27

ACLs vs CapabilitiesACLs

• Slow: OS has to read ACL for each object accessed.

• Easy to find/change rights on a particular object.

• Difficult to revoke privileges for a specific subject.

Capabilities

• Fast: OS always knows subject identity.

• Easy to find/change rights on a particular subject.

• Difficult to revoke privileges to a subject object.

Page 28: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #28

UNIX Access Control Model• UID

– integer user ID – UID=0 is root

• GID– integer group ID– Users can belong to multiple groups

• Objects have both a user + group owner.• System compares object UID with EUID.

– EUID identical except after su or SETUID.

Page 29: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #29

UNIX File PermissionsThree sets of permissions:

– User owner– Group owner– Other (everyone else)

Three permissions per group– read– write– execute

• UID 0 can access regardless of permissions.• Files: directories, devices (disks, printers), IPC

Page 30: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #30

UNIX File PermissionsBest-match policy

– OS applies permission set that most closely matches.

– You can be denied access by best match even if you match another set.

Directories– read = listing of directory– execute = traversal of directory– write = add or remove files from directory

Page 31: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #31

Special File PermissionsEach object has set of special permission bits

sticky• On a directory, means users can only delete files that

they own

setuid• Execute program with EUID = owner’s UID

setgid• Execute program with EGID = owner’s GID• On directories, causes default group owner to be that

of directory owner’s GID.

Page 32: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #32

Changing Permissions: chmodSet specifiers

– u = user– g = group– o = other

Permissions– r = read– w = write– x = execute

# remove other accesschmod o-rwx *.c

# add group r/w accesschmod g+rw *.c

# allow only you accesschmod u=rwx *

Page 33: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #33

Octal Permission NotationEach set (u,g,o) is represented by an octal digit.Each permission (r,w,x) is one bit within a digit.ex: chmod 0644 file

u: rw, g: r, o: r

ex: chmod 0711 binu: rwx, g: x, o: x

4 read setuid

2 write setgid

1 execute sticky

Page 34: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #34

Changing Ownershipnewgrp

– Group owner of files is your default group.– Changes default group to another group to

which you belong.chgrp

– Changes group owner of existing file.chmod

– Changes owner of existing file.– Only root can use this command.

Page 35: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #35

Default Permissions: umask• Determines access permissions given to

newly created files• Three-digit octal number

– Programs default to 0666– Umask modifies to: 0666 & ~umask– ex: umask=022 => file has mode 0644– ex: umask=066 => file has mode 0600

Page 36: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #36

setuid/setgid• Solution to UNIX ACLs inability to directly

handle (user, program, file) triplets.• Process runs with EUID/EGID of file, not

of user who spawned the process.• Follow principle of least privilege

– create special user/groups for most purposes• Follow principle of separation of privilege

– keep setuid functions/programs small– drop privileges when unnecessary

Page 37: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #37

Limitations of Classic ACLsACL control list only contains 3 entries

– Limited to one user.– Limited to one group.

Root (UID 0) can do anything.

Page 38: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #38

POSIX Extended ACLsSupported by most UNIX/Linux systems.

– Slight syntax differences may exist.getfaclsetfacl

– chmod 600 file– setfacl -m user:gdoor:r-- file– File unreadable by other, but ACL allows gdoor

Page 39: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #39

Immutable FilesImmutable Files on Linux

– chattr +i– Cannot delete, rename, write to, link to– Applies to root too– Only root can remove immutable flag

Immutable Files on FreeBSD– chflags +noschg– Cannot be removed by root in securelevel >0

Page 40: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #40

Host-based Access Control• /etc/hosts.allow and /etc/hosts.deny• used by tcpd, sshd, other servers• Identify subjects by

– hostname– IP address– network address/mask

• Allow before Deny– use last rule in /etc/hosts.deny to deny all

Page 41: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #41

Windows NT Access Control• Security IDs (SIDs)

– users– groups– hosts

• Token: user SID + group SIDs for a subject• ACLs on

– files and directories– registry keys– many other objects: printers, IPC, etc.

Page 42: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #42

Standard NT Permissions• Read: read file or contents of a directory• Write: create or write files and directories• Read & Execute: read file and directory attributes,

view directory contents, and read files within directory.

• List Folder Contents: RX, but not inherited by files within a folder.

• Modify: delete, write, read, and execute.• Full Control: all, including taking ownership and

changing permissions

Page 43: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #43

Windows NT Conflict Resolution1. If user not present in ACL and not a

member of any group in ACL, access is denied.

2. If ACL explicitly denies user access, access is denied.

3. Otherwise, if user named in ACL, user has union of set of rights from each ACL entry in which user is named.

Page 44: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #44

Special NT Permissions• Traverse Folder/Execute File• List Folder/Read Data• Read Attributes• Read Extended Attributes• Create Files/Write Data• Create Folders/Append Data• Write Attributes• Write Extended Attributes• Delete Subfolders and Files• Delete• Read Permissions• Change Permissions• Take Ownership

Page 45: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #45

SQL Access Control• Subjects

– Users.– Roles.

create role facultygrant faculty to james

• Objects– Databases, tables, table columns.

• Rights– Select, insert, update, delete, references, grant.

Page 46: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #46

SQL Access Control• The grant command gives access to a user

grant select on students to jamesor a role:grant select, insert, update on grades to faculty

and includes power to grant options:grant insert on students to registrar with grant option

• The revoke command removes accessremove insert on grades from faculty

Page 47: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #47

Hardware ProtectionConfidentiality

– Processes cannot read memory space of kernel or of other processes without permission.

Integrity– Processes cannot write to memory space of

kernel or of other processes without permission.

Availability– One process cannot deny access to CPU or other

resources to kernel or other processes.

Page 48: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #48

Hardware Mechanisms: VM• Each process has its own address space.

– Prevents processes from accessing memory of kernel or other processes.

• Attempted violations produce page fault exceptions.– Implemented using a page table.– Page table entries contain access control info.

• Read• Write• Execute (not separate on Intel CPUs)• Supervisor (only accessible in supervisor mode)

Page 49: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #49

VM Address Translation

Page 50: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #50

Hardware Mechanisms: RingsProtection Rings.

– Lower number rings have more rights.– Intel CPUs have 4 rings

• Ring 0 is supervisor mode.• Ring 3 is user mode.• Most OSes do not use other rings.

– Multics used 64 protection rings.• Different parts of OS ran in different rings.• Procedures of same program could have different

access rights.

Page 51: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #51

Hardware Mechanisms: Privileged Instructions

• Only can be used in supervisor mode.• Setting address space

– MOV CR3• Enable/disable interrupts

– CLI, STI• Reading/writing to hardware

– IN, OUT• Switch from user to supervisor mode on

interrupt.

Page 52: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #52

Hardware Mechanisms: System Timer

• Processes can voluntarily give up control to OS via system calls to request OS services.– SYSENTER, INT 2e

• Timer interrupt– Programmable Interval Timer chip.– Happens every 1-100 OS, depending on OS.– Transfers control from process to OS.– Ensures no process can deny availability of

machine to kernel or other processes.

Page 53: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #53

Why is Access Control hard?• Complex Objects

– Identifying objects of interest.• Is your choice of objects too coarse or fine-grained?

– Hierarchical structure like filesystem or XML• Subjects are Complex

– Identifying subjects of interest.– What are the relationships between subjects?

• Access Control states change.• Security objectives often unclear.

Page 54: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #54

Key Points• Center of gravity of security; pervasive.• Access Control Matrix simplest abstraction

mechanism for representing protection state.• ACM is too big, so real systems use either:

– ACLs: columns (objects) of ACM.– Capabilities: rows (subjects) of ACM.

• Access Control in Practice: UNIX.• Access control rests on hardware foundation.

– Virtual memory, rings, privileged instructions.

Page 55: CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Access Control.

CIT 380: Securing Computer Systems Slide #55

References1. Anderson, Ross, Security Engineering, Wiley,

2001.2. Bishop, Matt, Introduction to Computer Security,

Addison-Wesley, 2005.3. Bovet, Daniel and Cesati, Marco, Understanding

the Linux Kernel, 2nd edition, O’Reilly, 2003.4. Silberschatz, et. al., Database System Concepts,

4th edition, McGraw-Hill, 2002.5. Silberschatz, et. al., Operating System Concepts,

7th edition, Wiley, 2005.6. Viega, John, and McGraw, Gary, Building Secure

Software, Addison-Wesley, 2002.