Access Control

Carlo U. Nicola, FHNW With extracts from publications of : John Mitchell Stanford; Luca Vigan U. Freiburg i.B.; Samson Garfinkel, Gene Spafford, Chris Clifton, Purdue University.

Access Control Matrices: a practical abstraction for security

AS HS 10 2

Topics
! Access Control Matrix ! Access Control List ! Administration of ACM/ACL ! ACL in Java (class exercise) ! Security and ACL ! Bell-LaPadula security policy ! Biba security policy ! Role based security ! Practical example: Android security ! A refined definition of secure

AS HS 10 3

ACM/ACL: Example from the real world

AS HS 10 4

Access Control Goal: Specify the limits within which a legitimate user can work with the system.

AS HS 10 5

Glossary of terms Authentication establishes/verifies the identity of the requester. ! Requester presents credentials: something he knows (password); he possesses (smartcard) or he is (biometric). Authorization: Has the legitimate (authenticated) requester the right to perform the action? ! AC/authorization decision made by agent(s) in charge. Auditing process gathers data to discover violations or diagnose their cause. ! Offline after the fact, or online in real time (intrusion detection).
AS HS 10 6

Access Control Matrices Goal: How to describe the protection state of a system A solution: Access control matrix (ACM)
Describes protection state precisely between subjects and objects. Matrix elements describe the rights of subjects over the objects. State transitions change the elements of a matrix. Example: Linux from kernel 2.4 (getfactl, setfactl) and in Windows XP professional, Windows 7.
Linux: setfacl -m user:ulisse:r-- myfile.txt ! adds one entry to ACM for the file myfile.txt which gives ulisse read only permission.
AS HS 10 7

ACM construction An ACM is a static structure to regulate access to resources Objects (entities) o1 Subjects s1 s2 sn rj om
,sn } Objects: O = { o1, ,om } Rights: R = { r1,,rk } Entries: M[si, oj] R M[si, oj] = { rx, , ry } means subject si has rights rx, , ry over object oj
AS HS 10 8

Subjects: S = { s1,

ACM example 1 Processes p, q Files f,g Rights r,w,x,a (all),o (owner) f g p p rwo r rwxo q a ro r

q w rwxo

AS HS 10 9

ACM example 2

Procedures: inc_ctr, dec_ctr, manage Variable: counter Rights: +, , call counter inc_ctr dec_ctr manage inc_ctr + dec_ctr manage call call call

AS HS 10 10

ACM example (Linux)

attribute: Special modes like SUID base permissions Normal Unix file modes owner(nic): rwUser access group(chem): rwGroup access others: r-Other access extended permissions enabled More specific permissions entries whether they are used or not specify r-- u:harvey Permission r for user harvey deny -w- g:organic Deny w-rights for group organic permit rw- u:hill, g:bio Permissions rw for hill when in group bio

AS HS 10 11

AC policies versus AC mechanisms

Subjects (e.g. users, agents) detain privileges (e.g. rwx) on objects (e.g. data, programs, devices) according to AC policies (models). ! Policy: specifies how accesses are controlled and access decisions determined. Discretionary AC. Mandatory AC. Role-based AC. ! Mechanism (structure): implements or enforces a policy. Access matrix. AC list (ACL). Capability list. Separation policiesmechanisms allows for abstraction and independence.
AS HS 10 12

ACM commands' structure

Model by Harrison, Ruzzo & Ullman: in general, changes to the state of the system are modelled by commands of the form:

AS HS 10 13

API for primitive operations (1)

A set of six primitive operations are sufficient to undertake a meaningful transition from state (S,O,M) to state (S',O',M'):

Assumption for the next slide: all subjects are objects, i.e. S O .
AS HS 10 14

API for primitive operations (2)

AS HS 10 15

Creating a file Process p creates file f with r and w permissions:

command create-file(p,f) create object f; enter own into M[p,f]; enter r into M[p,f]; enter w into M[p,f]; end

AS HS 10 16

Mono-Operational commands

Mono-operational command: A single primitive operation is used in this command. Example: Make process p the owner of file g:

command make-owner(p,g) enter own into M[p,g]; end

AS HS 10 17

Conditional commands Mono-conditional command: A single condition is used in this command. Example: Let p give q right r over f, if p owns f:
command grant-read-file-1(p,f,q) if own in M[p,f] then enter r into M[q,f]; end

AS HS 10 18

Multiple conditions Let p give q r and w rights over f, if p owns f and p has c rights over q:
command grant-read-file-2(p,f,q) if own in M[p,f] and c in M[p,q] then enter r into M[q,f]; enter w into M[q,f]; end

Notice: c right means copy permission.

AS HS 10 19

Right to copy Allows possessor to give rights away. Often it is attached to a right, so it only applies to that right: ! r is read right that cannot be copied ! rc is read right that can be copied Important question: Is the copy flag copied when giving the r(rc) right? ! It depends on model and how the model is implemented
AS HS 10 20

Owner's rights Usually the system allows the possessor to change the entries in the ACM column: ! So the owner of an object can add, delete rights for others on its object. ! But it may depend on what the system allows: Cant give rights to specific (set of) users Cant pass copy flag to specific (set of) users

AS HS 10 21

Attenuation of privilege This principle says you cant give away rights you do not possess. See point 1 of Saltzman/Schrder. Pro: ! Restricts addition of rights within a system However this principle is usually ignored for the owner of an object. The reason for doing so, is that the owner gives herself rights, she gives them to others, and she, of course, can delete them.

AS HS 10 22

Summary ! Access control matrix is the simplest abstraction mechanism for representing a protection state within a system. ! Transitions alter the protection state. ! Six primitive operations alter the AC matrix: Transitions can be expressed as commands composed of these operations and, possibly, conditions.

AS HS 10 23

AC structures In large systems the matrix will be big and sparse. Therefore in practice, the matrix is implemented as a list. AC matrix AC list (ACL) A Capability List

AS HS 10 24

Two implementation concepts

Access control list (ACL): Store column of matrix with the resource Capability: User holds a ticket for each resource Two variations: store row of matrix with user, under OS control File 1 unforgeable ticket in user space
User 1 read write -

File 2 write write -

Access control lists are widely used, often with groups Some aspects of capability concept are used in Kerberos,

User 2 User 3 User m

read

read

write

write

AS HS 10 25

Capabilities
Operating system concept: of the future and always will be Examples: Dennis and van Horn: MIT PDP-1 Timesharing Hydra, StarOS, Intel iAPX 432, Eros, Amoeba: distributed, unforgeable tickets References: Henry Levy, Capability-based Computer Systems

http://www.cs.washington.edu/homes/levy/capabo ok/
Tanenbaum, Amoeba papers
AS HS 10 26

ACL vs Capabilities (1)

Access control list: Associate list with each object Check user/group against list Relies on authentication: need to know user Capabilities: Capability is unforgeable ticket Random bit sequence, or managed by OS Can be passed from one process to another Reference monitor checks ticket Does not need to know identify of user/process

AS HS 10 27

ACL vs Capabilities (2)

User U Process P User U Process Q User U Process R

Capabilty c,d Process P Capabilty c Process Q Capabilty c Process R

AS HS 10 28

ACL vs Capabilities (3)

Delegation:

! Capability: Process can pass capability at run time ! ACL: Try to get owner to add permission to list?
More common: let other process act under current user Revocation:

! ACL: Remove user or group from list ! Capability: Try to get capability back from process?
Possible in some systems if appropriate bookkeeping OS knows which data is capability If capability is used for multiple resources, have to revoke all or none Indirection: capability points to pointer to resource If C P R, then revoke capability C by setting P=0
AS HS 10 29

Capability list
Composability of Authorities: Resources are Subject.

No designation without authority ! Access controlled delegation channel

r and w rights in a capability list and in a resource are distinguishable and different operations

AS HS 10 30

Authorization relation

Sorted by objects: ACL. Sorted by subjects: Capability list. Relational database management systems use such a representation.

AS HS 10 31

AC policies As already stated the ACM model permits to define three types of access control security policies: Discretionary AC (Dt.: Nach Ermessen) Mandatory AC (Dt.: Verbindliche Zugriffskontrolle) Role-based AC. (Dt.: Rollenbasierte Zugriffskontrolle) It means that subjects (i.e. users, agents) detain privileges (i.e. rcwx) on objects (i.e. data, programs, devices) according to these AC security policies.

AS HS 10 32

Discretionary AC (DAC) This policy restricts access to system objects based on the identity of the users and/or the groups to which they belong. One simple DAC is represented by the Unix scheme owner/group/other. Permissions as tags: -rw-r--r-x 1 ulisse ibneco 56789 Dec
15:19 foo.bar

Temporary permissions: setuid programs allow users to accomplish tasks for which they normally would not have proper authorization (i.e. password change).
AS HS 10 33

Discretionary AC (2)
Two types of DAC policies are used in practice: Closed DAC: authorization must be explicitly specified, since the default decision is always denial. (Apache security policy). Open DAC: denials must be explicitly specified since the default decision is always access. ( Web portal through a HTML form).
General problems with DAC policies: Danger of users' mistakes or negligence; The dissemination of information is not controlled: for example a user who is able to read data can pass it to other users not authorized to read it without the actual owner knowing it.

AS HS 10 34

Mandatory AC (MAC)
As we will see in the Bell-LaPadula model one can assign centrally, sensitivity labels to all system objects and subjects and enforce that these rules are obeyed.

Idea: each subject and each object is assigned a security level.

(1) (2) Subject's label (clearance) specifies the level of trust associated with that subject. Object's label specifies the level of trust that a subject must have to be able to access that file.

The clear advantage of such a policy is the reduction of possible damage, but you pay this with the loss of flexibility.
AS HS 10 35

Multi-Level Security (MLS) Concepts

Military security policy:

Classification involves sensitivity levels, compartments Do not let classified information leak to unclassified files

Group individuals and resources:

Use some form of hierarchy to organize policy

Other policy concepts:

Separation of duty Chinese Wall Policy

AS HS 10 36

Military security policy Sensitivity levels ! compartments Satellite data Afghanistan Middle East Israel Top Secret Secret Confidential Restricted Unclassified
AS HS 10 37

A more civilian version Product specifications Discontinued In production OEM Internal Proprietary Public

AS HS 10 38

Bell-LaPadula (BLP) policy model (1)

(i) The Simple Security Policy: no process may read data at a higher level. No Read Up (NRU) or: a subject can only read an object of less or equal security level. (ii) The *-property: no process may write data to a lower level. No Write Down (NWD) or: a subject can only write into an object of greater or equal security level.

top secret secret confidential Set of actions: read, write, append, execute

AS HS 10 39

Bell-LaPadula (BLP) policy model (2)

Set of subjects S and objects O. Each subject s 2 S and each object o 2 O have a fixed security class L(s) (clearance) and a classification L(o) . Each subject has a maximal and an actual security level. Security classes are ordered: TS (Top Secret) < S < C < UC (Unclassified) Then:
(i) The Simple Security Policy: Subject s may read object o, if and only if L(o) L(s) . (ii) The *-property: If subject s has read access to object o, then s may write to object p if and only if L(o) L(p).

Basic Security Theorem: Let be a system with a secure initial state 0 and let T be a set of transformations. If every set of T preserve (i) and (ii) then every state i, i 0 is secure.
AS HS 10 40

Example
t s o4 o5 o6 o7 o8 o9 c u o10 o11 o12

Bob has his maximal and actual level set to s (secret) :

No read-up (read)

No write down (append)

o1 o2 o3

append

read append write

read

If Bobs actual level is set to c (confidential) :

t s c u o1 o2 o3 o4 o5 o6 o7 o8 o9 o10 o11 o12 8 oi that Charlie can read we have : li l1 o1 o2 o3

t o4 o5 o6

s o7 o8 o9

u o10 o11 o12

AS HS 10 41

MAC: Lattice of security levels

Bell-LaPadula should answer uniquely to questions like: ! Given 2 objects at different security levels, what is the minimal level a subject must have to be allowed to read both objects? Given 2 subjects at different security levels, what is the maximal level an object can have so that it still can be read by both subjects?

AS HS 10 42

Biba Integrity Model Rules that preserve integrity of information Two properties: Simple integrity property: A subject s may write object o only if L(s) L(o) (Only trust s to modify o if s has higher rank ) *-Property: A subject s with read access to o may write object p only if L(o) L(p) You may only write p if o more (Only move info from o tobelowisyour trusted classification and only read above your than p) classification
AS HS 10 43

Other policy concepts Separation of duty:

If amount is over $10,000, check is only valid if signed by two authorized people Two people must be different Policy involves role membership and physical difference

Chinese Wall Policy: Lawyers L1, L2 work in the same firm If company C1 sues C2: ! L1 , L2 can each work for either C1 or C2 ! No Li can work for opposite sides in any case Permission depends on use of other permissions These policies cannot be represented using access matrix
AS HS 10 44

Role-based access control (RBAC)

Permissions are associated with (i) roles (= set of actions and responsibilities, associated with particular working activities), and (ii) users/subjects became members of appropriate roles. This policy simplify the management of permissions because: ! All access decisions are based on roles that individual users have as part of an organisation. ! Roles can have overlapping responsibilities and privileges. ! Roles can be updated without updating the privileges of every user on individual basis. ! With RBAC one can introduce enterprise-specific security policies.
RBAC is closely related with the idea of user groups, namely a role links a set of users with a set of permissions
AS HS 10 45

RBAC example
RBAC are hierarchies with delegation of powers and rights.
In the example on the left side a user of role doctor has access to all transactions defined between intern and healer. The user with role healer on the contrary is restricted to his resources. A doctor can delegate a task to an intern or to a healer.

RBAC allows for least privilege (Saltzmann, Schrder) since a user with higher privileges doesn't need to activate them until he really needs them. RBAC does require (i) some rules for role assignments and authorization and for transaction authorization and (ii) rules for delegation of credentials. A RBAC security policy is fully implemented in JAAS.

AS HS 10 46

A practical example: Android security

AS HS 10 47

Android (1)
Open-source platform (Open Handset Alliance) Native development, Java development Platform outline:

! ! ! !

Linux kernel 2.6 Webkit-based browser engine SQLite as DB Open SSL, Bouncy Castle crypto API and Java library ! Bionic C library (small code, good performance, no GPL) ! Apache Harmony libraries (open source Java implementation) ! Many others: video stuff, Bluetooth, vibrate AS HS 10 48 phone, etc.

Android (2)

AS HS 10 49

Android challenges Battery life: ! Developers must conserve power ! Applications store state so they can be stopped (to save power) and restarted (helps with DoS attacks) ! The most foreground activity is never killed Android market: ! Not reviewed by Google (not like Apple!) ! No way of stopping bad applications from showing up on market ! Malware writers may be able to get code onto platform: shifts focus from remote exploit to AS HS 10 50 privilege escalation

Application = set of components

Basic components: Activity: defines the user interface: Example: scroll through your inbox Email client comprises many activities Service: Java daemon that runs in background Example: application that streams an mp3 in background Content provider Store and share data using a relational database interface Broadcast receiver mailboxes for messages from other applications

AS HS 10 51

Components: message passing system

Intents : asynchronous messaging system Signal an intent to switch from one activity to another Example: email app has an inbox, a compose activity, a viewer activity User click on inbox entry fires an intent to the viewer activity, which then allows the user to view that email

AS HS 10 52

Security step 1: Signing Developers sign applications ! Self-signed certificates:

Is not a form of identity It is used to allow the developer who built the application to post updates It is based on Java key tools and jar signer

AS HS 10 53

Security step 2: Application sandbox Application sandbox Each application runs with its UID (Linux process) with its own Dalvik virtual machine: ! Provides CPU protection, memory protection ! Authenticated communication protection using Unix domain sockets ! Only zygote (spawns another process) and ping run as root Applications announces permission requirement (security policy): ! Create a white list model: user grants AS HS 10 54 access

Security step 2: Linux and ACL

Two forms of security enforcement 1. Each application executes with its own user identity as Linux process 2. Android middleware has a reference monitor that mediates the establishment of inter-component communication (ICC) First is straightforward to implement, second requires careful consideration of mechanisms and security policy
AS HS 10 55

Android policy enforcement

Android focuses on Inter Component Communication (ICC) whose security policy is defined in the Android manifest file. It allows developers to specify an high-level ACL to access the components: 1. Each component can be assigned an access permission label 2. Each application requests a list of permission labels (fixed at install)
AndroidManifest.xml AndroidManifest.xml

From: Enck, et al. IEEE Security & Privacy, Jan./Feb.(2009) p.50-57

AS HS 10 56

Android manifest file

Each Android application has an AndroidManifest.xml file which describes all the components it uses. Components cannot execute unless they are listed. In the file we specify:
Rules for auto-resolution Runtime dependencies Optional runtime libraries Access rules Required system permissions

The manifest file spells out the security policy of the whole application
AS HS 10 57

Android manifest file is a security policy file!

<?xml version="1.0" encoding="utf-8" ?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package=ch.fhnw.apsi.friendviewer" android:versionCode="1" android:versionName="1.0.0"> <application android:icon="@drawable/icon" android:label="@string/app_name"> <uses-library android:name="com.google.android.maps" /> <activity android:name=".FriendViewer" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name="FriendMap" android:exported="false" /> <receiver android:name="FriendReceiver android:permission="ch.fhnw.apsi.permission.BROADCAST_FRIEND_NEAR"> <intent-filter> <action android:name="ch.fhnw.apsi.action.FRIEND_NEAR" /> </intent-filter> </receiver> </application> API protection <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="ch.fhnw.apsi.permission.READ_FRIENDS" /> <uses-permission android:name="ch.fhnw.apsi.permission.FRIEND_NEAR" /> </manifest> AS HS 10 58

Android components interaction

From: Enck, et al. IEEE Security & Privacy, Jan./Feb.(2009) p.50-57

AS HS 10 59

Android public and private components

The components of an application can be public or private. The manifest schema defines an exported attribute. It specifies whether the activity can be launched by components of other applications (true|false). If false, the activity can be launched only by components of the same application or applications with the same user ID. Unfortunately the default depends on complicated intent-filter rules! Implication: Components may unknowingly be (or become) accessible to other applications. Always set the exported attribute explicitly to true or false, especially if a sub-Activity returns a result.
<activity android:name="FriendMap" android:exported="false" />
AS HS 10 60

Android implicitly opens components

If the manifest file does not specify an access permission on a public component, any component in any application can access it.

This is defensible when for instance some components provide global access: e.g., the main Activity for an Application. Implication: Unprivileged applications have access Components without access permissions should be exceptional cases, and possible inputs must be carefully analysed (consider splitting components).

<activity android:name="FriendMap" android:exported="false" />

AS HS 10 61

Android intent broadcast permissions

The code broadcasting an Intent can set an access permission restricting which Broadcast Receivers can access the Intent. Thus we specify explicitly which application can read the broadcast. Implication: If no permission label is set on a broadcast, any unprivileged application can read it. Always specify an access permission on Intent broadcasts (unless you specify the destination explicitly).
// Notify any receivers if (location.distanceTo(floc) <= mDistThreshold) { Intent i = new Intent(ACTION_FRIEND_NEAR); i.putExtra(FriendContent.Location._ID, ***.Location._ID))); i.putExtra(FriendContent.Location.NICK, ***.Location.NICK))); i.putExtra(FriendContent.Location.CONTACTS_ID, ***.CONTACTS_ID))); sendBroadcast(i, ch.fhnw.apsi.permission.FRIEND_NEAR"); }
AS HS 10 62

Android content provider permissions

Content Providers have two additional security features: (i) separate read and write access permission labels, and (ii) URI permissions to specify which data subsets of the parent content provider permission can be granted for. These features give more control over application data Implication: Content sharing need not be all or nothing. URI permissions allow delegation (must be allowed by Provider) Always define separate read and write permissions. Use URI permissions to delegate rights to other components.
<provider android:authorities="friends" android:name="FriendProvider" android:readPermission=ch.fhnw.apsi.permission.READ_FRIENDS" android:writePermission="ch.fhnw.apsi.permission.WRITE_FRIENDS"> </provider>
AS HS 10 63

Android service hooks

A Service may arbitrarily invoke the checkCallingPermission() method to expand the ICC reference monitor. Allows Services to differentiate access to specific methods. Implication: The application developer can add reference monitor hooks Use checkCallingPermission() to mediate administrative operations. Alternatively, create separate Services.
private final IFriendTracker.Stub mBinder = new IFriendTracker.Stub() { public boolean isTracking() {return mTracking;} public boolean addNickname(String nick, int contactId) { if (FriendTracker.this.checkCallingPermission(PERMISSION_FRIEND_SERVICE_ADD) != PackageManager.PERMISSION_GRANTED) { throw new SecurityException("Requires " + PERMISSION_FRIEND_SERVICE_ADD); } ... } };
AS HS 10 64

Permission categories
Permissions can be: (1) normal : always granted; (2) dangerous : requires user approval; (3) signature : matching signature key; (4) signatureOrSystem: same as signature, but also system apps (legacy compatibility) Defence against malicious applications that may request sensitive informations. Implication: Users may not understand implications when explicitly granting
permissions.

Use signature permissions for application suites and dangerous permissions otherwise and always include informative descriptions
<permission android:name="ch.fhnw.apsi.permission.FRIEND_NEAR android:label="@string/permlab_friendNear" Defined in string.xml android:description="@string/permdesc_friendNear android:protectionLevel="dangerous"> </permission>
AS HS 10 65

Summary

Android security model:

! OS user-isolation applied to all applications ! Reference monitor for inter-component communications (ICC)

Android expansion of the ACM model: Delegation (Be aware: Mechanisms that delegate rights are poorly understood!) Public and Private components Permission Granting using user's confirmation

AS HS 10 66

The meaning of secure

AS HS 10 67

What does it mean Secure? (1)

A secure system doesnt allow any violations of the security policy: Is this a good definition? Yes, but too general Can we use it? Lot of work Alternative view: A safe system ! A system that checks rights.

! We start with an access control matrix A ! We define leak (Dt. das Leck): A command can add right r to an element of A not containing r Safe: A system is safe with respect to r if r cannot be leaked
AS HS 10 68

What does it mean Secure? (2)

Given: initial state X0 = (S0, O0, A0) Set of primitive commands c Can we reach a state Xn where s,o such that Mn[s,o] includes a right r not in M0[s,o]? If so, the system is not safe But is safe secure? It depends from the answer to the question: "Are the commands correctly implemented?"

AS HS 10 69

Unix example
General ACM for Unix:

! root has access to all files ! Owners have access to all their own files
Is it safe with respect to file access right?

! NO: chmod/chown command changes owners/rights! ! Only root can get root privileges ! Only users can authenticate themselves
Is this definition of safe useful? Safe does not differentiate between unauthorized and authorized leaks of rights. If we introduce the notion of transfer of rights to trusted subjects and eliminate those subjects from the AC matrix then the definition is quite useful, even in this case.
AS HS 10 70

Security frameworks

protect NSA: hunt defend Commercial:

prevent react detect

minimize
AS HS 10 71