04 - access control

The goal of access control is to protect confidentiality and integrity of information. Controlling what a subject can do (by regulating the operations that can be executed by a subject on data and resources) can help in preventing damage to the system.

• typically, access control is provided as a part of operating systems and database management systems

RFC 4949

(Access control is) a process by which use of system resources is regulated according to a security policy and is permitted only by authorized entities (users, programs, processes, or other systems) according to that policy.

concepts

access control modes

Discretionary Access Control (DAC)

Controls access based on the identity of the requestor and its access rules, stating what requestors are or are not allowed to do.

• an entity may be granted access rights that permit it to enable another entity to access some resource

The rules are often provided via access matrix, access control list (ACL) or extended access control matrix.

access matrix

• an empty cell means that no access rights are granted

Access Control Lists

• defines a list called “access control list” for each object, which enumerates the subjects that have access rights and, for each subject, which rights

ACLs take a subject-centered approach to access control.

It can also be seen this way, from the subjects’ perspective:

extended access control matrix

• the extended control marix considers the ability of one subject to transfer rights, create another subject and have ‘owner’ access rights to it
• it can also define a hierarchy of subjects
• certain subjects have the authority to make specific changes to the access matrix

Access by a subject to an object is mediated by the controller for that object. The controller’s decisions are based on the contents of the matrix.

traditional UNIX file access control

permessi di accesso

Il proprietario di un file definisce i permessi di accesso (chi può leggere, scrivere, eseguire un file). Sono visualizzabili con ls o stat.

più informazioni sui significati dei permessi

permessi speciali

I permessi speciali sono setuid, setgid e sticky bit.

Nella notazione ottale, sono specificati nel primo numero, in questo modo:

• 4 = setuid
• 2 = setgid
• 1 = sticky bit

(il bit assumerà come valore la somma tra i permessi speciali attivi).

Nella notazione a stringa, invece, il carattere che indica il permesso speciale assume la posizione del permesso di esecuzione. Se il file ha anche il permesso di esecuzione, la lettera che rappresenta il permesso speciale sarà minuscola altrimenti, sarà maiuscola).

• s nella prima terna di permessi ⟶ setuid
• s nella seconda terna di permessi ⟶ setgid
• t (nell’ultima terna di permessi) ⟶ sticky bit

esempio

6760/rws rwS ---

• setuid e setgid sono attivi
• il primo numero è 6 (= 4 + 2)
• l’utente ha il permesso di esecuzione, quindi la s è minuscola
• il gruppo non ha il permesso di esecuzone, quindi la S è maiuscola

sticky bit (t)

Se applicato sulle directory, corregge il comportamento di w+x (che permette la cancellazione di file in una directory su cui si hanno i permessi w+x senza avere permessi di scrittura sui file stessi) permettendo la cancellazione dei file solo se si hanno permessi di scrittura su di essi.

• inutile se applicato su file

esempio

Se un utente U vuole quindi cancellare un file f in una directory D:

• senza sticky bit, gli sarà sufficiente avere i diritti di scrittura su D
• con lo sticky bit, gli sono necessari anche i permessi di scrittura su f

setuid bit (s)

Si usa sui file eseguibili. Quando vengono eseguiti, i privilegi con cui opera il corrispondente processo non sono quelli dell’utente che esegue il file ma quelli dell’utente proprietario del file.

• per esempio, il comando passwd ha il setuid (infatti permette ad un utente di modificare la propria password)

setgid bit (s)

Analogo di setuid, ma con i gruppi (i privilegi sono quelli del gruppo che è proprietario del file eseguibile).

• può essere applicato ad una directory, e in quel caso ogni file creato al suo interno ha il gruppo della directory anziché quello primario di chi crea i file

settare permessi

Per settare permessi, si usa il comando chmod mode [, mode...] filename. Il comando segue un formato ottale:

• si usano 4 numeri tra 0 e 7, come dalle tabelle sopra
• il primo numero indica setuid, setgid e sticky
• gli altri sono per utente, gruppo e altri
• si possono fornire solo 3 numeri se si assumono setuid, setgid e sticky settati a 0

chmod ha anche una modalità simbolica che utilizza le lettere per settare i permessi:

• il formato è: [ugoa][+-=][perms...], dove:
• u = user, g = group, o = other, a = all
• perms è:
  • zero
  • una o più lettere nell’insieme {rxwXst}
    • X = permesso di esecuzione condizionato (si aggiunge x solo se l’elemento è una directory, o almeno uno degli altri utenti (u/g/o) ha già il permesso di esecuzione)
  • una lettera nell’insieme {ugo} ⟶ aggiunge i permessi dell’insieme corrispondente (dell’utente/del gruppo/di others)

cambiare il proprietario

Per cambiare il proprietario di un file, si usa chown [-R] proprietario {file} (è possibile specificare anche un gruppo), mentre per cambiare la proprietà di gruppo di un file, si usa chgrp [-R] gruppo {file}.

• se il file è una directory, con la flag -R si applica il comando anche a tutte le sottodirectory

Link to original

Many modern UNIX systems support access control lists (Linux, FreeBSD, OpenBSD…).

When a process requests access to a file system object, the appropriate ACL is selected, and the matching entry is checked for the correct permissions.

Mandatory Access Control (MAC)

Each subject and each object are assigned a security class (which often form a hierarchy and are called “security levels”).

• a subject is said to have a security clearance of a given level
• an object is said to have a security classification of a given level
• unlike with DAC, users cannot share or change the access permissions of data they own (access is enforced by the system)

Multilevel Security (MLS)

The MLS model defined four access modes:

• read (read-only)
• append (write-only)
• write (both read and write)
• execute (neither read nor write, but execute-only)

Confidentiality is achieved if a subject at a high level cannot convey information to a subject at a lower level, unless it is thanks to an authorised declassification. (It is achieved through:)

• no read up: a subject can only read objects of $\le$ security level
  • called the simple security property (‘ss-property’)
• no write down: a subject can only write into an object of $\ge$ security level
  • called the star property (’*-property)

Models like this (i.e.Bell-LaPadula model) are limited because they cannot manage the “downgrade” of objects (they have a very rigid structure).

Role-Based Access Control (RBAC)

Role-Based Access Control is based on the definition of roles and the specification of access rights for those roles, rather than for subjects directly.

goals

• describing organizational access control policies
• roles are based on job function
• flexibility and scalability are increased

Families of RBAC Models

RBAC0 is the “base model”, and each model implements new “features”.

• RBAC1 ⟶ hierarchy
  • roles have a hierarchal structure - many operations are common to a large number of roles, so some roles subsume others, and there is inheritance among roles.
  • the hierarchy is based on a partial order (like $\le$, so a relation that is reflective, transitive and antisymmetric) that goes from top to bottom
• RBAC2 ⟶ constraints
  • constraints relating to the roles are added
  • some types include:
    • mutually exclusive roles
    • cardinality (maximum number of roles that can be given to a user)
    • prerequisite roles (a user can only be assigned a role if it is already assigned to another specified role)
• RBAC3 ⟶ hierarchy + constraints

Attribute-Based Access Control (ABAC)

Authorizations can express conditions on properties of both the resource and the subject.

• very flexible
  • systems are capable of enforcing DAC, RBAC and MAC concepts
  • an unlimited number of attributes can be combined to satisfy any rule
• the main obstacle is it could be demanding (performance-wise) to evaluate predicates on both resources and users for each access

ABAC relies on policies (sets of rules and relations that govern allowable behaviour within an organisation, based on the privilege of subjects and how resources or objects are to be protected under which environment conditions) and privileges (authorised behaviours of a subject, defined by an authority and embodied in a policy).

The ABAC attributes can be divided into:

• subject attributes ⟶ define the identity and characteristics of a subject (active entity that can change the system state)
• object attributes ⟶ can be used to make access control decisions (objects are passive entities containing or receiving information)
• environmnet attributes ⟶ describe the operational/technical/situational environment or context in which the information access occurs

ABAC policy model

• $S$, $O$ and $E$ ⟶ subjects, objects and environments
• $S{A}_k(1\dots k\dots K)$, $O{A}_m(1\dots m\dots M)$, $E{A}_n(1\dots n\dots N)$ ⟶ pre-defined attributes for subjects, objects and environments
• $ATTR(s)$, $ATTR(o)$ ⟶ examples of attribute assignment relations
• the access rule states whether a subject $\text{can\_access}$ an object in a given environment. it is determined by a function $f$ that evaluates the collection of attributes for subject, object and environment

$$\text{can\_access(s,o,e)←f(ATTR(s),ATTR(o), ATTR(e))}$$

ABAC vs RBAC

• In RBAC, as the number of attributes grows, the number of roles and permissions grows exponentially
• ABAC deals with additional attributes more efficiently