Transcript Document

IS 302: Information Security and
Trust
Week 10: Access Control
2012
Access Control
•
Who can access what and how in a
shared system
I. DAC
II. MAC
III. RBAC
© Yingjiu Li 2007
2
I. Discretionary Access Control
•
DAC
1)
2)
3)
4)
AC matrix
ACL
Capabilities
Authorization relations
© Yingjiu Li 2007
3
1) Access Control Matrix
objects (and subjects)
F
G
U
orw
subjects
rights
V
© Yingjiu Li 2007
r
orw
o – own
r – read
w – write
4
Subjects
• Are subjects users?
user
principals
subjects
© Yingjiu Li 2007
5
User - Principals
• One to many mapping
between user and
principals
• System authenticates user
in the context of principal
Alice.Top-secret
Alice
Alice.Secret
Bob.Dean
Bob
Bob.Faculty
• Shared principals
(accounts) are not good
for accountability
Bob.Super-user
user
© Yingjiu Li 2007
principals
6
Principal - Subjects
• One to many mapping
between principal and
subjects
• A subject is a program or
application run on behalf
of principal
Email
Alice.
Topsecret
Word
Database
• Subjects are often treated
the same as principal if all
subjects of a principal
have the same rights
© Yingjiu Li 2007
principal
subjects
7
Objects
• An object is anything on which a subject can
perform operations (mediated by rights)
• Usually objects are passive, for example
– File
– Directory (or Folder)
– Memory segment
• But, subjects can also be objects, with operations
– Kill
– Suspend
– Resume
© Yingjiu Li 2007
8
Rights
• A right specifies what kind of access a
subject can perform on an object
–
–
–
–
–
–
–
Own
Read
Write
Execute
Create
Delete
Transfer
© Yingjiu Li 2007
9
Implementation of Access Control
Matrix
ACL
objects
subjects
U
F
G
orw
Capabilities
rights
V
© Yingjiu Li 2007
r
orw
10
2) Access Control List (ACL)
• ACL – Each column of access control matrix is stored with
corresponding object
F
U:o
G
V:o
U:r
V:r
U:w
V:w
V:r
• ACL requires subjects to be authenticated before access to a particular
object
© Yingjiu Li 2007
11
3) Capabilities
• Capabilities – Each row of access control matrix is stored with
corresponding subject
U
F/o, F/r, F/w
V
F/r, G/o, G/r, G/w
• Capabilities do not require subjects to be authenticated but require
– Capabilities are unforgeable
– Propagation of capabilities are under control
© Yingjiu Li 2007
12
Capabilities
• Propagation of capability
capability
capability
F/r, F/t
F/r
t: transfer
A
B
C
User
User
User
© Yingjiu Li 2007
Ref. INFS762 Sushil Jajodia 1999
13
Comparison of ACL and
Capabilities
• ACL
– Access rights stored with
objects
– Requires authentication of
subjects
– Provides access review on a
per-object basis
– Most operating systems
such as UNIX and
Windows use ACL to
protect files
© Yingjiu Li 2007
• Capabilities
– Access rights stored with
subjects
– Requires unforgeability of
capabilities and propagation
control of capabilities
– Provides revocation
facilities on a per-subject
basis
– Used in authentication
systems such as Kerberos
14
4) Authorization Relation
• Besides ACL and capabilities, access matrix can also be
implemented/stored in relation form
subject
access right
object
U
U
U
V
V
V
V
o
r
w
r
o
r
w
F
F
F
F
G
G
G
• This form is often used in database management systems
© Yingjiu Li 2007
15
Case Study: UNIX File System
• 3 types of permissions
(rights)
– r – read file or directory
– w – write to file or directory
– x – execute file or search
directory
• 3 types of users (subjects)
– u – user who owns file
– g – members of the group to
which the owner belongs
– o – all other users
© Yingjiu Li 2007
• Given a file (object), each
of 3 permissions can be
set for any of 3 types of
users by its owner
– user group
– rwx rwx
others
rwx
– ls -l file1
– -rwx--x--x 2 Alice staff
2048 Jan 1 12:10 file1
– ls -l dir1
– drwxr-xr-x 3 Alice user
1024 Jan 1 09:27 dir1
– chmod g+r file1
16
Windows File System
• File/folder  permissions  user/group of
users
•
•
•
•
•
Read
Write
Change owner
Delete
…
© Yingjiu Li 2007
17
Security Problems of DAC
• However, DAC dose not provide real assurance – access
restrictions can be easily bypassed
– Trojan horse attack
ACL
Principal U
r
w
File F
U:r
U:w
Principal V
r
File G
U:w
V:r
Principal V is an adversary who wants to read file F
© Yingjiu Li 2007
18
Security Problems of DAC
• Principal V sends U a benign software with Trojan horse
embedded
• U executes the software  Trojan horse gains U’s
privileges
ACL
exe
r
U:r
Principal U
File F
Trojan horse
U:w
Benign software
Principal V
r
File G
U:w
V:r
Principal V can now read file F with the help of Trojan horse
© Yingjiu Li 2007
19
II. MAC
• Mandatory Access Control (MAC)
– MAC augments DAC based on security labels
attached to subjects and objects
• Security label to subject  security clearance
• Security label to object  security classification
– Users have no control of security labels, but
information flow is restricted to certain canflow paths
© Yingjiu Li 2007
20
Security Labels
Top secret
High
level
Secret
Can-flow
Confidential
Low
level
© Yingjiu Li 2007
Unclassified
21
BLP Model (1)
• Bell and LaPadula model (BLP)
– A formal MAC model
– D. E. Bell and L. J. LaPadula. Secure computer
systems: mathematical foundations and model.
Technical report, MITRE, 1974
© Yingjiu Li 2007
22
BLP Model (2)
• Simple-security property
– Subject S can read object O
only if
• Information can flow from
label(O) to label(S)
Read down
Label(S)
Can-flow
Label(O)
• Star-property
– Subject S can write object
O only if
• Information can flow from
label(S) to label(O)
Write up
Label(O)
Can-flow
Label(S)
© Yingjiu Li 2007
23
BLP Model (3)
• Note
– BLP model is applied to subjects, not users
• Users are trusted
• Subjects are not trusted due to Trojan horses
– Star-property prevents information leakage
caused by Trojan horses
• Why – see next slide
© Yingjiu Li 2007
24
BLP Model (4)
• DAC:
Principal U
exe
Trojan horse
r
File F
U:r
U:w
r
File G
U:w
V:r
r
File F
U:r
U:w
Benign software
Principal V
• BLP:
Principal U exe
(Label H)
can-flow
(Label L)
© Yingjiu Li 2007
Trojan horse
Benign software
Principal V
star-proprety
r
File G
U:w
V:r
25
III. Role-Based Access Control
(RBAC)
• MAC
– Security labels are used
– Access control is
strictly regulated by
dominance function of
labels
– Suitable for secure
computer systems
• Orange Book US DoD
standard – 1983
• Common Criteria
international standard –
2005
© Yingjiu Li 2007
• RBAC
– No formalized labels
– No dominance (canflow) function; access
is less regulated
– Suitable for
commercial app
• General, flexible and
easy-to-use
• NIST-ANSI RBAC
standard –2001
26
Role
• Role represents users
– Specific task competency
– Job responsibility
– Specific duty assignment
• Role defines permissions
– Student role in eLearn
– Professor role
– Admin and security officer role
user
UA: user
assignment
role
PA: permission
assignment
permission
Sessions (one-tomany mapping)
© Yingjiu Li 2007
27
Security Management
• Security management is simpler with roles
– User-role relationship changes over time
– Role-permission relationship is relatively stable
dynamic
user
UA: user
assignment
stable
role
PA: permission
assignment
permission
flexible
Sessions (one-tomany mapping)
© Yingjiu Li 2007
28
Hands-on Exercise
• Access Control in Java
– Access control modifiers
– SecurityManager: access control and
enforcement
© Yingjiu Li 2007
29
Access Control Modifiers
Modifiers
public
Class
accessibility
All
protected
N/A
default
Same package
private
N/A
© Yingjiu Li 2007
Member
accessibility
All if class is
accessible
Same package
or subclass
Same package
Same class (not
subclass)
30
Exercise on AC Modifiers
• Download
– InputCredit.java
– WriteCredit.java
• Make them work
© Yingjiu Li 2007
31
SecurityManager Class
• Full-time security guard
– Enforce security policies
• what a program is allowed to do
– Request permission for certain operations
• read, write, delete, execute
• system commands (exit)
– By default, no SecurityManager
© Yingjiu Li 2007
32
Exercise on SecurityManager (1)
• Get the current SecurityManager
SecurityManager security =
System.getSecurityManager();
if (security != null) {
security.checkExit(status);
}
. . . // code continues here if checkedExit() not throw a
SecurityException
• Each operation has its own checkXXX() method
– Write your own security manager
– Override SecurityManager’s checkXXX() to tighten or
modify the security policy for specific operations
© Yingjiu Li 2007
33
Exercise on SecurityManager (2)
• Download
– PasswordSecurityManager.java
– WriteCreditCheck.java (which incorporates
PasswordSecurityManager in WriteCredit.java)
– ReadCredit.java
• Task
– Incorporate PasswordSecurityManager into
ReadCredit.java  ReadCreditCheck.java
– Enforce password checking for reading credit card
number from a file
© Yingjiu Li 2007
34
Exercise on SecurityManager (3)
• Rewrite PasswordSecurityManager and
incorporate it into ReadCredit.java 
ReadCreditCheck.java
• Block any reading from file credit.txt
© Yingjiu Li 2007
35
Review
•
Which of the following is subject to Trojan horse attack?
1. DAC
2. MAC
3. RBAC
•
Which of the following is used in secure operating
systems?
1. DAC
2. MAC
3. RBAC
•
Which of the following is a NIST standard?
1. DAC
2. MAC
3. RBAC
© Yingjiu Li 2007
36
Individual Assignment 2 (5%)
• Due in next week (hard copy during class)
– Textbook 4.10 Exercise 22 (page 227 in 3rd
edition, page 240 in 4th edition)
– Textbook 5.11 Exercise 1 (page 305 in 3rd
edition, page 316 in 4th edition)
– Textbook 7.11 Exercises 19, 43, 62 (pages 486488 in 3rd edition, pages 504-507 in 4th edition)
© Yingjiu Li 2007
37
Announcement
• Week 11: lab session at SEIL Rm 5013 SoE building
• Week 12: project presentation
– Teams 1-8, part A, 20 minutes
• Week 13: project presentation
– Teams 9-10: part A and part B, 30 minutes
– Teams 1-8: part B demo and presentation, 10 minutes
• Week 14: project report due on April 9, Monday
• Week 15: final exam (40%) 1~3pm, April 25 (please
double check)
© Yingjiu Li 2007
38