Authentication and Authorization
Slide credits: Dr Daniele Sgandurra (Royal Holloway, University of London, UK)
Dec 3rd, 2018 2
Authentication
Dec 3rd, 2018 3
Objectives
• Introduce need for user authentication (and distinguish from identification).
• Cover three main classes of user authentication methods, based on either:
• something known;
• something possessed;
• personal characteristics (biometrics).
• Look at specific examples of user authentication techniques.
• Introduce notion of identity management.
Dec 3rd, 2018 4
Agenda
• Introduction
• Verification by something known
• Verification by something possessed
• Verification by personal characteristics • Identity management
• Resources
Dec 3rd, 2018 5
Identification
• Very often need to identify ourselves to a system. • Typically involves providing a user name, which is
mapped to an existing account.
• Account defines rights and privileges on system.
• Identification is a one-to-many (or 1:N) process – identifies users from an existing set of users.
Claiming an identity
Dec 3rd, 2018 6
Authentication
• Need for identity verification:
• computer access;
• entry to secure areas;
• financial security (e.g., ATMs, e-commerce).
• Note important difference between identification information (unique name) and information to verify a claimed identity.
• Authentication is a one-to-one (1:1) operation, unlike identification.
Verifying a claimed identity
Dec 3rd, 2018 7
Why user authentication?
• In order to control access to resources and make system users accountable for their actions, a system must:
• be able to associate access requests and actions with specific users.
• This requires the means to:
• reliably identify users;
• associate users with the programs they execute (and actions the programs perform).
Dec 3rd, 2018 8
User accounts
• System maintains list of authorised users, and has a user account for each user (created at time of enrolment).
• This account is associated with:
• identifying and authenticating information (e.g.,
username and password) for user.
• User must be identified and authenticated before system use.
• After identification and authentication, the user account is associated with every program run by user.
Dec 3rd, 2018 9
Computer/user interactions I
• An authenticated user is associated with a program that gives access to system resources, e.g. programs, printers, files.
• This program is automatically executed after successful authentication of the user:
• e.g., bash/shell.
Dec 3rd, 2018 10
Computer/user interactions II
• Older systems, e.g. MS DOS, provide a command line interface (CLI) – a shell:
• users interact with OS by typing instructions (program names and parameters) at prompt.
• Current systems such as Windows provide a desktop and a graphical user interface:
• users interact with operating system by selecting items from menus or clicking icons.
Dec 3rd, 2018 11
Computer/user interactions III
• Shell or desktop program associated with authenticated user’s account:
• all programs executed are associated with account; • so requests received from, and performed by, an
application program can be associated with a user. • Hence can:
• enforce security requirements of form ‘Alice can read file.txt but Bob cannot’ (authorisation);
• determine which user (Alice or Bob, say) performed a security-related action (audit and accountability).
Dec 3rd, 2018 12
Difficulties
• Computers, unlike humans, have no built-in means of identifying and authenticating people.
• Computer will not know if impostor (Alice) enters Bob’s username and password.
• One reason for many vulnerabilities in computer systems:
• user authentication often relies on knowing a shared secret – passwords often not ‘strong’.
Dec 3rd, 2018 13
Classification
• Can classify user authentication (identity verification) methods into three types:
1. by something known,
2. by something possessed,
3. by physical characteristic (or by result of involuntary action).
• Can consider first two (something you have) and last two (something you are) together.
• Can also potentially authenticate users by context (e.g., location).
Dec 3rd, 2018 14
Agenda
• Introduction
• Verification by something known
• Verification by something possessed
• Verification by personal characteristics • Identity management
• Resources
Dec 3rd, 2018 15
Not Examinable
Something known
• Obvious example is use of passwords (human/human or human/computer).
• Obvious security precautions for passwords: • individual passwords (for accountability);
• do not write passwords down; • make them hard to guess;
• Alternative: lists of one-time passwords.
Dec 3rd, 2018 16
Not Examinable
Human to computer authentication
• Authentication often based on knowledge of a shared secret (the password):
• when user account is created (user registration) the user selects (or is given) a password p;
• system stores the password itself or a value derived from this password.
Dec 3rd, 2018 17
Not Examinable
Password abuse
• Many (most?) users, for obvious reasons:
• choose poor passwords;
• do not maintain the secrecy of their passwords; • re-use passwords.
• Users often:
• write their password on a piece of paper stuck to their monitor or
kept under their keyboard;
• tell other people their password;
• log on to their machine and then leave it unattended.
• Training and security awareness are very important, but users have limits …
• What is a good password?
• As random as possible.
Dec 3rd, 2018 18
Not Examinable
Random sequence
• Intuitively, a sequence S is random if there is no method to describe it (=an algorithm that generates it) that is represented with a shorter length than S:
• i.e., if a given sequence S can be compressed, then it is not random.
• Two characteristics of a random sequence:
• uniform distribution (same probability for each possible
character);
• independence (output of t should be independent of t-1).
Dec 3rd, 2018 19
Not Examinable
Password entropy
• Entropy is a measure of unpredictability of information content.
• Password entropy is based on the character set used (i.e., use of lowercase, uppercase, digits and symbols) as well as password length.
• Password entropy predicts how difficult a given password would be to crack through guessing, brute force cracking, dictionary attacks or other common methods.
Dec 3rd, 2018 20
Not Examinable
Password entropy
• Expressed in terms of bits: a password that is already known has zero bits of entropy:
• one that would be guessed on the first attempt half the time would have 1 bit of entropy.
• A password’s entropy can be calculated by finding the entropy per character:
• log base 2 of the number of characters in the character set used, multiplied by the number of characters in the password itself.
• Password with entropy of n bits is equivalent to n-bit (truly) random symmetric key at withstanding brute force attack.
Dec 3rd, 2018 21
Not Examinable
Choice of character set (English keyboards)
• Lowercase letters = 26
• Uppercase letters = 26
• Digits = 10
• Punctuations & special characters = 32
• Lowercase + uppercase = 52 • +digits = 62
• +special chars = 94
Dec 3rd, 2018 22
Not Examinable
Password entropy
• How many bits needed to represent symbols from symbol set:
• Digits, 0 . . . 9è3.32 (2^3.32=10)
• English letters, a . . . Zà4.70
• Printable ASCII characters (94)à6.55
Dec 3rd, 2018 23
Not Examinable
User chosen passwords
• People have a hard time remembering random passwords: • so we may let them pick their own.
• People pick bad passwords:
• passwords that are easy to remember are often easy to
guess;
• use common words;
• frequency distributions of characters;
• phone number, street address, SSN, dog’s name, birthday, …
• Sophisticated attacker takes advantage of this with (possibly large) dictionaries of common passwords.
Dec 3rd, 2018 24
Not Examinable
Entropy of User Chosen Passwords
• No really rigorous way to estimate.
• Propose starting from Shannon’s estimate of entropy in
English text:
• C. E. Shannon, “Prediction and Entropy of Printed English” Bell System Technical Journal, v.30, n.1, 1951, pp. 50-64;
• one of the most widely referenced papers in computing; • it seems to be relatively little progress beyond Shannon.
• Shannon used 26 English letters plus space.
Dec 3rd, 2018 25
Not Examinable
Password storage
• How should lists of passwords be stored?
• If unencrypted then readable by systems staff
(damages accountability).
• Usual solution – hide them using a one-way
function (easy to compute, very difficult to invert). • Check password by applying function and
comparing with list entry.
Dec 3rd, 2018 26
Not Examinable
Unix password protection
• Unix uses a one-way function to protect its password list.
• Two extra features originally implemented:
• slow encryption (25 iterations of DES – now
replaced with MD5/SHA-256/SHA-512); • password salting.
• Salting makes pre-encrypted dictionary attack difficult and prevents entire list being attacked simultaneously.
• (e.g., prevents rainbow table attacks)
Dec 3rd, 2018 27
Not Examinable
Strength of passwords (attacker view)
• 𝑥” = number of possible passwords (x cardinality of symbol set, y = length).
• Suppose an offline attack:
• attacker can try n password per seconds:
• e.g., 10% tries/second; & • it can parallelize: e.g., 1000 CPUà10 .
Dec 3rd, 2018 28
Not Examinable
Password attacks
• Brute-force attack:
• try all possible combinations.
• Dictionary attack:
• try most common passwords and dictionary words.
• Rainbow table:
• list of precomputed hashes of all combinations (up to a
certain length – typically 13).
• Birthday attack:
• collision in hashes.
Dec 3rd, 2018 29
Not Examinable
Agenda
• Introduction
• Verification by something known
• Verification by something possessed
• Verification by personal characteristics • Identity management
• Resources
Dec 3rd, 2018 30
Not Examinable
Tokens
• Idea of authentication token well-established:
• keys for doors, cabinets, cars, …
• magnetic stripe cards – used for ATMs, access control to secure sites, …
• Problems with copying.
• Typically used in conjunction with a password or PIN, and hence as part of a dual-factor authentication scheme.
Dec 3rd, 2018 31
Not Examinable
Multi-Factor Authentication (MFA)
• Presenting several separate pieces of evidence to an authentication mechanism:
• from different categories.
• Two-factor authentication (2FA):
• confirming user’s identity with a combination of two different components;
• e.g., withdrawing cash from ATM
• bank card (something that the user possesses) + PIN
(something that the user knows).
Dec 3rd, 2018 32
Not Examinable
Using magnetic stripe cards
• Problems arise because of easy forging/copying. • Hologram (on card) added to prevent changing
embossed data.
• Many schemes devised to make forging/copying difficult.
Dec 3rd, 2018 33
Not Examinable
Smart cards (IC cards)
• Contain microprocessor, RAM and ROM.
• More memory than magnetic stripe cards.
• Communicate with reader via plated areas on card (positions/protocols standardised in ISO/IEC 7816, a multi-part standard).
• Copying much more difficult.
• 1st generation cards had primitive processors and limited memory (8 kbytes).
Dec 3rd, 2018 34
Not Examinable
Agenda
• Introduction
• Verification by something known
• Verification by something possessed
• Verification by personal characteristics • Identity management
• Resources
Dec 3rd, 2018 35
Not Examinable
Why personal characteristics?
• Passwords may be revealed or guessed.
• Tokens may be lost or stolen.
• Personal characteristics may be harder to forge. Long history of use.
• Device that measures characteristics must be trusted (e.g., physically secure) otherwise replay may be possible.
Dec 3rd, 2018 36
Not Examinable
What is biometrics?
• Term derived from the Greek words bio (= life) and metric (= to measure).
• In general, biometrics is the measurement and statistical analysis of biological data.
• In IT, biometric recognition refers to measuring human body characteristics for authentication/verification (1:1) and/or identification (1:N) purposes.
• Definition by Biometrics Consortium – automatically recognising a person using distinguishing traits.
Dec 3rd, 2018 37
Not Examinable
How does it work?
• Every individual is physically unique.
• To devise a biometric authentication method, must
consider:
• what are the distinguishing traits that make each person unique?
• how can these traits be measured?
• how different are the measurements of these
distinguishing traits for different people?
Dec 3rd, 2018 38
Not Examinable
Biometric identifiers (I)
• Ideal identifier (distinguishing trait) should possess the following properties:
• universality: nearly all people in the target population should have the characteristic;
• uniqueness: the characteristic of each individual should be unique, i.e. the biometric feature of each individual in the population should be different from that of every other individual;
• stability: the characteristic should neither change with time nor allow alteration;
• collectability: possible to measure the characteristic quantitatively.
Dec 3rd, 2018 39
Not Examinable
Biometric identifiers (II)
• performance: achievable identification accuracy, speed, memory requirements;
• acceptability: the extent to which people are willing to accept a particular biometric system in their daily lives;
• forgery resistance: how easy it is to fool the biometric system by fraudulent methods (particularly relevant when technique used for authentication).
Dec 3rd, 2018 40
Not Examinable
Biometric technologies
• Key technologies include:
• fingerprint biometrics – fingerprint recognition;
• eye biometrics – iris and retinal scanning;
• face biometrics – face recognition using visible or infrared light (facial thermography);
• hand geometry biometrics – also finger geometry;
• signature biometrics – signature recognition;
• voice biometrics – speaker recognition.
Dec 3rd, 2018 41
Not Examinable
Other biometric methods
• Many other schemes in the literature, e.g.: • vein recognition (hand);
• palmprint;
• gait recognition;
• body odour measurements; • ear shape;
• DNA;
• keystroke dynamics.
Dec 3rd, 2018 42
Not Examinable
Some biometric technologies
Dec 3rd, 2018 43
Not Examinable
Possible decision outcomes
• An impostor is rejected.
• An impostor is accepted (Type I error).
• A genuine individual is accepted.
• A genuine individual is rejected (Type II error).
Dec 3rd, 2018 44
Not Examinable
Errors
• Balance needed between 2 types of error:
• TypeI:systemacceptsimpostor(‘falsematch’ or ‘false acceptance’);
• Type II: system fails to recognise valid user (‘false non- match’ or ‘false rejection’).
• Application dependent trade-off between two error types.
• In most cases, Type I errors are more serious.
Dec 3rd, 2018 45
Not Examinable
Liveness detection
In all these biometric systems, liveness detection is performed • Perspiration.
• Spectroscopic characteristics.
• Ultrasonic technology.
• Physical characteristics:
• temperature;
• hot and cold stimulus;
• pressure stimulus;
• electrical properties;
• bio-impedance;
• pulse;
• blood oxygenation.
• Camera and laser solutions.
Dec 3rd, 2018 46
Not Examinable
Fingerprint authentication
• Basic steps for fingerprint authentication: • imageacquisition;
• noisereduction;
• imageenhancement;
• featureextraction; • matching.
Dec 3rd, 2018 47
Not Examinable
Fingerprint processing
a) Original
b) Orientation
c) Binarised
d) Thinned
e) Minutiae
f) Minutiae graph
Dec 3rd, 2018
48
Not Examinable
Assessment – fingerprint recognition
Advantages: Disadvantages:
• mature technology;
• easy to use/non-intrusive;
• high accuracy (comparable to PIN authentication);
• long-term stability;
• ability to enrol multiple
fingers;
• comparatively low cost.
• inability to enrol some users;
• affected by skin condition;
• sensor may get dirty;
• negative association with forensic applications.
Dec 3rd, 2018
49
Not Examinable
Hand geometry measurements
Dec 3rd, 2018 50
Not Examinable
Assessment – hand geometry
Advantages:
Disadvantages:
• low accuracy;
• relatively high cost of
readers;
• relatively large readers;
• difficult for some users (e.g., children, arthritics, missing fingers, large hands).
• mature technology;
• non-intrusive;
• high user acceptance;
• no negative associations.
Dec 3rd, 2018 51
Not Examinable
Retinal scanners
Dec 3rd, 2018 52
Not Examinable
Assessment – retinal scanning
Advantages:
• potential for high accuracy;
• long-term stability;
• feature is protected from variations (regarding external environment);
Disadvantages:
• difficult to use;
• intrusive;
• perceived health threat;
• high sensor cost.
• genetic independence.
Dec 3rd, 2018 53
Not Examinable
Iris scanning
• Iris pattern has high degree of randomness: very accurate biometric.
• Genetic independence: identical twins have different iris patterns.
• Stable throughout life.
• Highly protected, internal organ of the eye.
• Patterns can be acquired at distance (1m).
• Not affected by contact lenses or glasses.
Dec 3rd, 2018 54
Not Examinable
Iris acquisition devices
Dec 3rd, 2018 55
Not Examinable
Assessment – iris recognition
Advantages:
• potential for high accuracy;
• resistance to impostors; • long term stability;
• fast processing.
Disadvantages:
• intrusive;
• privacy issues – possible that the state of health can be detected;
• high cost.
Dec 3rd, 2018 56
Not Examinable
Signature recognition
• Handwritten signatures are an accepted way to authenticate a person.
• Automatic signature recognition measures the dynamics of the signing process (rather than the finished signature).
• Signature generating process is a trained reflex – imitation difficult especially ‘in real time’.
Dec 3rd, 2018 57
Not Examinable
Dynamic signature recognition
• Variety of characteristics can be used: • angle of the pen;
• pressure put on the pen;
• total signing time;
• velocity and acceleration; • geometry.
Dec 3rd, 2018 58
Not Examinable
Assessment of signature recognition
Advantages: Disadvantages:
• resistance to forgery; • widely accepted;
• non-intrusive;
• no record of the signature.
• signature inconsistencies;
• may be difficult to use (special pens);
• largish templates (1 to 3 kbytes);
• problem with trivial signatures.
Dec 3rd, 2018 59
Not Examinable
Speaker verification
• Measure linguistic and speaker dependent acoustic patterns.
• Speaker’s patterns reflect:
• anatomy (size and shape of mouth and throat), • behavioural (voice pitch, speaking style).
• Heavy signal processing involved (spectral analysis, periodicity, etc.).
Dec 3rd, 2018 60
Not Examinable
Speaker recognition systems
• Three main types:
• text-dependent: predetermined set of phrases for
enrolment and identification;
• text-prompted: fixed set of words, but user prompted to avoid recorded attacks;
• text-independent: free speech, more difficult to accomplish.
Dec 3rd, 2018 61
Not Examinable
Assessment – speaker recognition
Advantages: Disadvantages:
• use of existing telephony infrastructure or simple microphones;
• easy to use/non- intrusive/hands free;
• no negative association.
Dec 3rd, 2018 62
• pre-recorded attack;
• variability of the voice
(ill or drunk);
• affected by background noise;
• large template (5 to 10 kbytes);
• low accuracy.
Not Examinable
Choosing biometrics I
• Does the application need identification or authentication?
• Is the collection point attended or unattended? • Are the users used to the biometrics?
• Is the application covert or overt?
Dec 3rd, 2018 63
Not Examinable
Choosing biometrics II
• Are subjects cooperative or non-cooperative? • What are storage requirement constraints?
• How strict are performance requirements?
• What biometrics are acceptable to users?
Dec 3rd, 2018 64
Agenda
• Introduction
• Verification by something known
• Verification by something possessed
• Verification by personal characteristics • Identity management
• Resources
Dec 3rd, 2018 65
Background and terminology
• When user wishes to access a service via the Internet, the service may want to know who user is (e.g., for charging purposes).
• User must provide identity, and also allow the service provider to authenticate the claimed identity (using credentials).
• In other cases, service provider may simply wish to know certain user characteristics or attributes (e.g., whether the user is over 18).
Dec 3rd, 2018 66
Identities
• User may have many identities (with identifiers) used with different service providers:
• employee may have an employee number for use with his/her employer;
• citizen has one or more numbers for interactions with government;
• user of Internet services (e.g., messaging) may have multiple names for a set of service providers.
Dec 3rd, 2018 67
Attributes
• More generally, users have many attributes, i.e. properties of them as individuals.
• Examples include: • age;
• sex;
• nationality;
• name;
• credit card number.
• Can define the identity to be set of all user attributes.
• Depending on service being provided, a service provider
may need to know some but not all attributes.
Dec 3rd, 2018 68
Credentials
• Service may ask user to use credentials to prove ownership of identity, e.g.:
• a password;
• a biometric sample;
• a public key certificate;
• a MAC computed using a shared secret key;
• a digital signature on a challenge provided by the service provider.
Dec 3rd, 2018 69
Authorisation
• Once entity has been authenticated, the service provider needs to decide whether or not to grant the requested service.
• This is authorisation, i.e. is holder of this identity authorised to access service?
• Could, for example, be supported using server-held Access Control Lists (ACLs).
Dec 3rd, 2018 70
Single Sign-On (SSO)
• Single Sign-On (SSO) is a widely used term.
• An SSO system enables a user to ‘log in’ just once, and thereafter be automatically logged in to a variety of different services.
• This simplifies password use and management for end user.
• SSO systems have existed for decades.
Dec 3rd, 2018 71
SSO systems
• Three SSO systems of practical importance: • OpenID;
• OAuth 2.0; and
• OpenID Connect – the successor to OpenID, which
builds on OAuth 2.0.
• We do not discuss details of these SSO systems in this course.
Dec 3rd, 2018 72
Note: CSRF attacks
• A recent large-scale study found that many websites do not properly implement use of the state variable, critical to avoiding CSRF attacks (pronounced “sea-surf”)
• Unlike XSS attacks, which exploit the trust that a user has in a website, the CSRF attack exploit the trust that a website has in the user’s browser.
• Other sites do not use the id token properly.
Dec 3rd, 2018 73
Agenda
• Introduction
• Verification by something known
• Verification by something possessed
• Verification by personal characteristics • Identity management
• Resources
Dec 3rd, 2018 74
Books
• The following books are relevant:
• D. Gollmann, Computer Security, 2011 (3rd edition),
Chapter 4.
• Ross Anderson, Security Engineering, Chapter 15.
• S. M. Bellovin, Thinking Security: Stopping Next Year’s Hackers, Chapter 7.
• P. Windley, Digital Identity. O’Reilly, 2005.
• S K Modi, Biometrics in Identity Management: Concepts to
Applications, Artech House, 2011.
Dec 3rd, 2018 75
Online resources
• The following resources are relevant:
• http://www.identityblog.com/ [Kim Cameron’s identity
weblog is here].
• http://www.kantarainitiative.org
• http://www.ietf.org [This is the IETF website from which
RFCs and Internet drafts can be obtained].
• http://www.microsoft.com [Information about CardSpace/InfoCard is available here].
• http://www.eclipse.org/higgins/ [Information about Higgins, the open source rival to CardSpace, is available here].
• http://oauth.net/ [This is the official OAuth site].
Dec 3rd, 2018 76
Biometrics resources
• There is a wide selection of literature on biometrics systems, including:
• ENISA briefing on behavioural biometrics;
• BSI PAS 92: 2010, Code of practice for the implementation of
a biometric system.
• ISO/IEC 24745, Information technology – Security techniques
– Biometric information protection.
• ISO/IEC 19792: 2009, Information technology – Security
techniques – Security evaluation of biometrics.
• ISO/IEC 24787: 2010, Information technology – Identification
cards – On-card biometric comparison.
Dec 3rd, 2018 77
OAuth/OpenID Connect security
• W. Li and C. J. Mitchell, ‘Security issues in OAuth 2.0 SSO implementations’, in: Proceedings of the 17th Information Security Conference, Hong Kong, China, 12- 14 October 2014 (ISC 2014), Springer-Verlag LNCS 8783 (2014), pp. 529-541.
• W. Li and C. J. Mitchell, ‘Analysing the security of Google’s implementation of OpenID Connect’, arXiv:1508.01707 [cs.CR], August 2015, 27 pages.
Dec 3rd, 2018 78
Authorization
Dec 3rd, 2018 79
Objectives
• Introduce notion of access control, and why it is needed.
• Introduce ACLs and capabilities.
• Consider information flow policies
• Review additional access control models.
• Describe the operations and properties of RBAC.
Dec 3rd, 2018 80
Agenda
• Access control basics
• ACLs and capabilities
• Information flow policies
• Authorization Models
• Role-Based Access Control • Resources
Dec 3rd, 2018 81
Some simple security questions
• Suppose a person wants to access a protected resource:
• How do we decide whether user is allowed to use resource?
• What do we need to know about the user?
• What do we need to know about the resource?
• How might we prevent the user from using the resource?
Dec 3rd, 2018 82
Computer security issues
• How do we control which people can use a computer system?
• How do we control which programs a user can run?
• How do we control which resources a process can
access?
• How do we protect processes that share computer resources from each other?
Dec 3rd, 2018 83
Fundamental techniques
• Memory protection:
• segmented virtual memory model prevents a process
reading or overwriting memory used by other processes • Authentication:
• verifies users’ identities
• Access control (authorisation):
• limits access to programs and resources
Dec 3rd, 2018 84
Access control terminology I
• Objects
• Resources (passive entities) in
computer system, e.g.: • Files;
• Directories; • Printers;
• Sockets.
• Subjects
• Active entities that access
resources, e.g.: • Process;
• Thread.
• Principals
• Entities that represent a
user, e.g.: • User;
• Group;
• Role;
• Cryptographic key.
• Principals can create subjects.
Dec 3rd, 2018
85
Overview
Dec 3rd, 2018 86
Access control terminology II
• A principal is an entity that can be granted access to objects or can make statements affecting control decisions.
• A subject is an active entity within an IT system.
• For the purpose of access decisions, subjects have to be bound to principals:
• when a subject requests access to a protected object, the reference monitor checks whether the principal bound to the subject has the right to access the object;
• example of a principal in a OS: user identity;
• example of a subject in OS: process running under a user identity (the principal).
Dec 3rd, 2018 87
Access control terminology III
• Reference monitor mediates all access requests by subjects.
• Security kernel consists of hardware, firmware and software in a trusted computing base that
implement the reference monitor; security kernel must:
• mediate all accesses;
• be protected from modification; • (ideally) be verifiable as correct.
Dec 3rd, 2018 88
Placing the reference monitor
• Hardware: access control mechanisms in microprocessors.
• Hypervisor: access control mediating access to HW.
• Operating system: access control in the kernel
• Service layer: access control in database systems, Java Virtual Machine, .NET Common Language Runtime, or middleware architecture.
• Application: security checks in the application code to address application specific requirements.
Dec 3rd, 2018 89
Reference Monitor: Design Choices
kernel supported (e.g., in OS)
interpreter
modified application (IRM)
program
RM
program
program
RM
RM
kernel
kernel
kernel
Dec 3rd, 2018
90
Security context
• Authorisation relies on user authentication.
• Decision whether or not to grant an access request
by a process based on security context of process: • security context is inherited from the user that initiated
the process;
• security context of a user identifies the user and any groups to which the user belongs.
Dec 3rd, 2018 91
What is access control?
• Generic term for process that controls interactions between users and resources.
• Access control system implements a security policy determined by:
• organisational requirements;
• statutory requirements (e.g., covering PII, including
medical records).
• Access control policy requirements include: • confidentiality(restrictionsonreadaccess);
• integrity(restrictionsonwriteaccess).
Dec 3rd, 2018 92
Why use access control?
• Prevents users from having unlimited access to system resources.
• Limit access of unauthorised users that manage to break in.
• Access control not required if access to resources does not need to be constrained.
• Early stand-alone PCs (DOS, Windows 95) could not (and did not need to) enforce access control.
Dec 3rd, 2018 93
Access control: schematic view
• User (actually a process acting on behalf of user) requests access (read, write, print, etc.) to a resource in the computer system.
• The reference monitor:
• establishes the validity of the request …
• … and returns a decision either granting or denying access.
Access Request
Decision
Reference monitor
Dec 3rd, 2018
94
Access modes
• Two basic modes of interaction between subject and object:
• observe (i.e., read); • alter (i.e., write).
• Accessing object = a flow of information:
• when observing (reading) an object – information flows
from object to subject;
• when altering (writing to) an object – information flows from subject to object.
Dec 3rd, 2018 95
Execute access
• Sometimes object can be accessed without using observe or alter mode, e.g.:
• running executable files (programs); • use of directories;
• use of cryptographic keys.
• Meaning of execute access depends on context, e.g. in Unix:
• execute access to directory = permission to access directory;
• read and execute access combined for a directory = permission to list contents of directory.
Dec 3rd, 2018 96
Access rights
• Access right = way of accessing objects.
• Interpretation of access right depends on: • operating system; e.g. in Multics:
• write access = read and write;
• append access = write-only (or ‘blind write’). • object type:
• in Unix, execute differs for programs & directories;
• Windows treats everything as an object (in programming
sense):
• access rights depend on class of an object;
• file access rights differ from directory access rights.
Dec 3rd, 2018 97
Permissions
• Permission refers to the access granted for an object and determine what a subject can do with it:
• if you have read permission for a file, you’ll be able to open it and read it.
• A right refers to the ability to take an action on an object (also at system level).
• A privilege is a permission to perform an action (combination of rights and permissions).
Dec 3rd, 2018 98
Administrative access rights
• Some rights are administrative, involving: • changing access control data structures;
• changing access rights of a user.
• Often related to ownership of resource. • Operations are controlled by:
• using a special change access rights command, e.g. chmod in Unix;
• granting control access rights and privileges to users (change permission and take ownership privilege in > Windows 2000).
Dec 3rd, 2018 99
Access control policies (I)
• Access control systems enforce policies.
• Discretionary Access Control (DAC) based on identities: • ownership of resources is typically important;
• Unix access control enforces such a policy;
• common in commercial systems.
• Mandatory Access Control (MAC) independent of identity: • characteristics of resources are important;
• access given if user/object in same domain;
• common in government/military systems.
Dec 3rd, 2018 100
Access control policies (II)
• Role-based access control (RBAC): a non-discretionary access control based on the subject’s role or position in the organization.
• Rule-based access control: when the access to an object is based on certain rules, e.g. based on the time of the day.
• Attribute-based access control (ABAC): access control is based on attributes, which are sets of labels or properties that can be used to describe all the entities that must be considered for authorization purposes (e.g., subject, objects and environment).
Dec 3rd, 2018 101
Delegation
• Sometimes it is necessary to allow a process to perform an access on behalf of another process.
• This creates need for delegation (temporary transfer) of access rights.
• Delegation typically built into access control systems.
• Delegation supported in Windows through technique called Impersonation.
Dec 3rd, 2018 102
Not Examinable
Types of access control
• Preventative. • Deterrent.
• Detective.
• Corrective.
• Recovery.
• Compensation. • Directive.
Dec 3rd, 2018 103
Not Examinable
How to implement them
• Administrative access controls:
• e.g. policies, procedures, security training, …
• Logical/technical access controls: • e.g., smartcards, passwords, ACL, …
• Physical access controls: • e.g., physical barriers, …
Dec 3rd, 2018 104
Not Examinable
Layered Controls
Dec 3rd, 2018 105
Agenda
• Access control basics
• ACLs and capabilities
• Information flow policies
• Authorization Models
• Role-Based Access Control • Resources
Dec 3rd, 2018 106
Models
• A model is an abstract way of describing a system.
• A model consists of:
• entities playing roles in the system,
• relations between entities, and
• operations that can be performed by, and on, entities.
• In the context of access control, a model typically describes a reference monitor.
Dec 3rd, 2018 107
Why are models useful?
• Can deduce formal results about security of a system from the model:
• e.g., given specification of security policy, we can answer the question “Does the system maintain the security policy?”
• Model may also generate rules that help with implementation.
• May also assist in verifying that implementation meets requirements.
Dec 3rd, 2018 108
Access control matrix I
• Simplest access control model.
• Introduced by Lampson (1971) and extended by Harrison,
Ruzzo and Ullman (1976-8): • columns indexed by objects;
• rows indexed by principals;
• matrix entries are (sets of) access operations.
• Foundation of many theoretical security models.
Objects Principals
trash
a.out
allfiles.txt
jason
{r,w}
{r,w,x}
{r,w}
mick
{r,x}
{r}
Dec 3rd, 2018 109
Access control matrix II
• Suppose a subject acting on behalf of principal p wants to access object o using access right a.
• Can represent request as triple: (p, o, a).
• Request is granted (by the reference monitor) if (and only if) a belongs to the access matrix entry corresponding to principal p and object o.
Dec 3rd, 2018 110
Access control matrix III
• The request (jason, allfiles.txt, w) will be granted.
• The request (mick, allfiles.txt, w) will be denied.
Objects Principals
trash
a.out
allfiles.txt
jason
{r,w}
{r,w,x}
{r,w}
mick
{r,x}
{r}
Dec 3rd, 2018 111
Disadvantages
• Abstract formulation of access control. • Not suitable for direct implementation:
• matrix is likely to be extremely sparse and therefore implementation is inefficient;
• management of matrix is likely to be extremely difficult if there are tens of thousands of files and hundreds of users (resulting in millions of matrix entries).
Dec 3rd, 2018 112
Access Control Lists (ACLs) I
• ACL corresponds to a column in an access control matrix.
• ACL for a.out would be
[(jason, {r,w,x}), (mick, {r,x})]
• How would reference monitor using ACLs check validity of request (jason, a.out, r)?
Objects Principals
trash
a.out
allfiles.txt
jason
{r,w}
{r,w,x}
{r,w}
mick
{r,x}
{r}
Dec 3rd, 2018 113
Access Control Lists II
• Represented internally as a (per-object) list of access control entries:
• each entry includes a user account identifier and an access mask.
• Access mask is a bit pattern in which each bit represents a particular access right.
• If bit is set then access is granted, e.g.:
• if 111 represents {r, w, x} then 100 represents {r} etc.;
• if jason’s account identifier is 138 and mick’s is 533, the ACL for a.out would be [(138, 111), (533, 101)].
Dec 3rd, 2018 114
Access Control Lists III
• ACLs focus on the objects:
• typically implemented at operating system level; • Windows uses ACLs.
• Disadvantage:
• how can we check the access rights of a particular subject efficiently?
Dec 3rd, 2018 115
Access Control Lists IV
• More than one ACL entry may be relevant: • group and user entries may both be relevant; • different entries may give different rights.
• ACL entries may contain negative rights.
• Typically access decision is made before complete
ACL is read.
• This means that order of processing entries is important.
Dec 3rd, 2018 116
Capability lists I
• Capability list corresponds to a row in an access control matrix.
• jason’s capability list would be
[ (trash, {r,w}), (a.out, {r,w,x}), (allfiles.txt, {r,w})].
• How would such a reference monitor check the validity of the request (jason, a.out, r)?
Objects Principals
trash
a.out
allfiles.txt
jason
{r,w}
{r,w,x}
{r,w}
mick
{r,x}
{r}
Dec 3rd, 2018 117
Capability lists II
• Capability lists focus on principals:
• typically implemented in services and application
software;
• e.g., database applications use capability lists to
implement access control for tables; • also relevant to distributed systems.
• Capabilities can be represented using object identifiers and access masks.
• Disadvantage:
• how to check which principals can access an object?
Dec 3rd, 2018 118
Agenda
• Access control basics
• ACLs and capabilities
• Information flow policies
• Authorization Models
• Role-Based Access Control • Resources
Dec 3rd, 2018 119
Information flow
• As previously stated, accessing a computer resource is like initiating an information flow:
• read access causes information to flow from an object to a subject;
• write access causes information to flow from a subject to an object.
Dec 3rd, 2018 120
Partial ordering
A partial ordering ≤ (“less or equal”) on a set of security levels L is a relation on L x L which is:
• reflexive – for all 𝑎 ∈ 𝐿, 𝑎 ≤ 𝑎 holds; •transitive–forall𝑎,𝑏,𝑐∈𝐿,𝑖𝑓𝑎 ≤𝑏𝑎𝑛𝑑𝑏≤
𝑐,𝑡h𝑒𝑛𝑎 ≤𝑐;
• antisymmetric – for all 𝑎,𝑏 ∈ 𝐿,𝑖𝑓 𝑎 ≤
𝑏𝑎𝑛𝑑𝑏 ≤𝑎,𝑡h𝑒𝑛𝑎=𝑏.
If two elements 𝑎, 𝑏 ∈ 𝐿 are not compatible, we write 𝑎 ≰ 𝑏.
Dec 3rd, 2018 121
Examples
• 𝑃 𝑋 ,⊆ ,thepowersetofasetXwiththesubset relation as partial ordering.
• (𝑁, |), the natural numbers with the ‘divides’ relation as partial ordering.
• The strings over an alphabet Σ with the prefix relation as a partial ordering. A string 𝛽 is a prefix of a string 𝛼 if there exists a string 𝛾 such that we canwrite𝛼= 𝛽𝛾.Inthiscase,wewrite𝛽≤𝛼.
Dec 3rd, 2018 122
Hasse Diagram
Dec 3rd, 2018 123
An information flow policy
• The following policy enforces confidentiality requirements:
• every object and principal has a security level (security label) – label for a subject is inherited from its principal;
• set of security labels is a partially ordered set;
• information flows must respect the partial ordering, so information can only flow from entity a to entity b if a ≤ b (where ≤ is the partial ordering).
Dec 3rd, 2018 124
Information flow policy – an example
s1 s2 ûü
o1 o2
o3 o4 ûü
High
Medium
• s2 can read o2
• s4 can write to o4
s3 s4
• s1 cannot write to o1
• s3 cannot read o3
Dec 3rd, 2018 125
Low
Direction of permitted information flow
Information flow policy properties
• What does such a policy prevent?
• Information leaks due to inappropriate reads:
• prevents unclassified user reading classified information. • Information leaks due to inappropriate writes:
• prevents Trojan horses downgrading classified information;
• prevents classified information being printed to an unclassified
printer.
• Leak prevention = confidentiality.
• If the direction of permitted information flow in the prior example is changed, it is possible to enforce integrity.
Dec 3rd, 2018 126
Agenda
• Access control basics
• ACLs and capabilities
• Information flow policies
• Authorization Models
• Role-Based Access Control • Resources
Dec 3rd, 2018 127
Not Examinable
The Bell-LaPadula Model
• Implements an information flow policy for confidentiality.
• Has two main components:
• a security lattice (i.e., a partially ordered set of security
labels), providing the mandatory access control element;
• a protection matrix, where this matrix refines the information flow policy (i.e., it adds discretionary access control).
• Disasvantages:
• Lacks relevance to commercial systems:
• modelonlycapturesconfidentiality(notintegrity); • designedforgovernment/militaryapplications.
• Lacks flexibility.
Dec 3rd, 2018 128
Not Examinable
Alternative Models
Be aware that there are other possible access control models:
• Biba
• Chinese wall • Clark-Wilson
(We do not discuss them.)
Dec 3rd, 2018 129
Not Examinable
Agenda
• Access control basics
• ACLs and capabilities
• Information flow policies
• Authorization Models
• Role-Based Access Control • Resources
Dec 3rd, 2018 130
Not Examinable
RBAC: Motivation
• Administration of access control systems can be time-consuming:
• system with 1000 users, 100 000 objects and 10 access rights has 1000 ́100 000 ́10 = 109 possible authorisation triples;
• default access rights for newly created objects, security groups and ACLs gives some reduction in administrative burden;
• big potential for mistakes and omissions.
Dec 3rd, 2018 131
Not Examinable
Core idea
• Central concept in Role Based Access Control (RBAC) is the role:
• acts as a bridge between users and objects;
• reduces complexity of configuring authorisation policy;
• can be used to automate ‘user provisioning’, by integrating authorisation and human resources databases.
Dec 3rd, 2018 132
Not Examinable
Privilege management
Dec 3rd, 2018 133
Not Examinable
RBAC – core components
• Users are associated with one or more roles (the UA relation).
• Permissions are associated with one or more roles (the PA relation).
• User activates a session (security context) by selecting one or more roles associated with user.
• Request granted if a role associated with user in this session has permission.
Dec 3rd, 2018 134
Not Examinable
RBAC model
UA PA
Dec 3rd, 2018 135
Not Examinable
RBAC – formal model
• In formal RBAC model we have:
• set of users U, set of roles R, set of operations A, and set
of objects O.
• Define:
• set of permissions: P ⊆ O ́A;
• user-role assignment relation: UA ⊆ U ́R;
• permission-role assignment relation PA ⊆ P ́R; • set of sessions S ⊆ U ́2R.
Dec 3rd, 2018 136
Not Examinable
Special types of RBAC
• Look at two special types of RBAC system: • hierarchical RBAC;
• constrained RBAC.
• Also briefly consider possible incompatibilities between these two types of RBAC system.
Dec 3rd, 2018 137
Not Examinable
Hierarchical RBAC
• Role hierarchy used to impose a structure on set of roles to further reduce the administrative burden:
• role hierarchy should match the organisational structure;
• more senior roles inherit the rights of subordinate roles.
Dec 3rd, 2018 138
Not Examinable
Hierarchical RBAC – formal version
• A role hierarchy is a partially ordered set (R,£).
• User assigned to a role r (via UA) is implicitly
assigned to all roles rʹ £ r.
• Permission assigned to a role r (via PA) is implicitly
assigned to all roles rʹ > r.
Dec 3rd, 2018 139
Not Examinable
Constrained RBAC
• Constraints are used to define and enforce separation of duty (SoD) requirements:
• some tasks need more than one user (‘two-man rule’, ‘four-eyes rule’, ‘dual control’);
• relevant permissions for such a task are assigned to different roles;
• membership of those roles is restricted by separation of duty constraints.
• Two constraint types: static and dynamic.
Dec 3rd, 2018 140
Not Examinable
Static SoD constraints
• Static separation of duty limits the assignment of users to roles:
• static SoD constraint is specified as a pair (Rʹ,n) where Rʹ⊆R and n is an integer;
• means a user cannot have n roles in set Rʹ;
• e.g. ({finClerk, poClerk}, 2) means a user cannot be assigned to both of the financial clerk and purchasing clerk roles;
• Static constraints enforced by the UA relation.
Dec 3rd, 2018 141
Not Examinable
Dynamic SoD constraints
• Dynamic separation of duty limits the activation of roles by users in sessions:
• dynamic SoD constraints are specified in the same way as static SoD constraints;
• dynamic constraints enforced by the authentication mechanism.
Dec 3rd, 2018 142
Not Examinable
Conflicts
• Possible issues arise when constrained RBAC used in conjunction with hierarchical RBAC.
• This is because a superior inherits the role assignments of all his/her subordinates:
• this seriously complicates checking of static and dynamic constraints;
• also means that changes in the hierarchy also involve checking all the constraints.
Dec 3rd, 2018 143
Not Examinable
RBAC administration I
• Changes may need to be made to the configuration of an RBAC system:
• assign (revoke) a user to (from) a role;
• assign (revoke) a permission to (from) a role; • add (delete) a role;
• add (delete) an edge from the role hierarchy.
• These functions need to be controlled.
Dec 3rd, 2018 144
Not Examinable
RBAC administration II
• Two possible approaches:
• assign special administrative permissions to (administrative) roles;
• issues arise because it may become hard to decide whether the system is ‘safe’,
• i.e. whether or not certain undesirable situations can arise; • use structure of role hierarchy to limit power of
(administrative) roles.
• Remains active area of current research.
Dec 3rd, 2018 145
Not Examinable
Use of RBAC
• Use of RBAC to manage user privileges is widely accepted as best practice.
• Many systems, including Microsoft Active Directory, Microsoft SQL Server, SELinux, FreeBSD, Solaris,
Oracle DBMS, and SAP R/3, implement some form of RBAC.
Dec 3rd, 2018 146
Not Examinable
Role mining – objective
• In practice defining the roles required for a large and complex system may be very difficult.
• Role mining is a technique intended to help optimise the process.
• Goal is to optimise security administration based on roles individuals play in organisation.
Dec 3rd, 2018 147
Not Examinable
Role mining – approaches
• Role mining can be done in three ways:
• bottom-up: users are given pre-existing roles based on
their skills or duties;
• top-down: roles are formulated to match the skills or duties of individual users
• by-example: roles are matched with user skills and duties as defined by managers.
• Tools exist to perform automated role mining.
Dec 3rd, 2018 148
Not Examinable
Practical issues with RBAC
• In practice RBAC may be difficult to administer on large systems.
• One problem of particular significance is known as role explosion.
• Administrators may have to maintain hundreds or even thousands of roles across several applications.
• Number of roles increases with number of connected systems; an organisation with a thousand employees can end up with several thousand roles!
• Limits usefulness of RBAC in practice.
Dec 3rd, 2018 149
Not Examinable
Agenda
• Access control basics
• ACLs and capabilities
• Information flow policies
• Authorization Models
• Role-Based Access Control • Resources
Dec 3rd, 2018 150
Reading I
• Books:
• D. Gollmann, Chapters 5 , 11, 12;
• M. Bishop, Chapters 2–7;
• Chandramouli, Ferraiolo and Kuhn, Role-based access control, Artech House, 2003.
• Standards and white papers: • XACML Version 2.0;
• ANSI RBAC Standard.
Dec 3rd, 2018 151
Reading II
• The NIST document: Assessment of Access Control Systems (Interagency Report 7316), is an interesting and accessible read.
Dec 3rd, 2018 152
Authorization in UNIX systems
Dec 3rd, 2018 153
Unix User Accounts
All user accounts are recorded in the file
/etc/passwd
• The Unix account identifier is the numeric UID
• The user name is associated with the UID merely for human convenience
• Every account also has a group identifier GID
/etc/passwd file is needed by a great many applications in order to link username to UID
• /etc/passwd is therefore “world readable”
Dec 3rd, 2018 154
•
•
Unix Permissions
Every file ( and device ) on a Unix system has an owner and a group
l Owner is a username on the system l Technically,anumericUID
l Group is a groupname on the system l Technically,anumericGID
l The Owner need not be a member of the Group
The owner and the group for a file are entirely independent of each other
l
l
Dec 3rd, 2018 155
Unix Permissions
Every file ( and device ) on a Unix system has a set of permissions associated with it
l Three types of permission:
l read
l write
l execute
l Permissions are granted in three categories: l user(owner)
l group l other
l
Dec 3rd, 2018 156
Unix Permissions
l Extremely simple security model (DAC) l No Access Control Lists by default
l (Butcanbeadded)
l Privilege is pretty much “All or nothing” l Rootvs.standarduser
l Rootcandoanything
Dec 3rd, 2018 157
Unix Permissions
The “mode” of a file determines which user/s are permitted different types of access
The owner of a file ( or the “root” superuser ) can always change the mode of a file
even if the mode denies access to the file for the owner ( which is perfectly possible ! )
l
l
l
Remember that a user can be a member of more than one group
l afilehasexactlyoneownerandonegroup
Dec 3rd, 2018 158
l
Unix Permissions (important slide)
Permissions apply to the most specific categorisation of the user requesting access
– If the user is the owner of the file, then the Owner permissions only are applied
– Otherwise, if the user is a member of the file’s group, then the Group permissions are applied
– Otherwise the Other permissions are applied
If the user requesting access is the owner, then the Group and Other permissions are irrelevant
l
l
Dec 3rd, 2018 159
Unix Permissions
l File mode usually written as: rwxrwxrwx l Can be expressed numerically, in octal
l user, group, other
l read, write, execute
l e.g.: -rw-r—–
-rw-r–r– -rw-rw-r– -r–r—–
antony users 11264 Jun 23 13:45 antony users 13156 Sep 25 00:05 antony users 7680 Jun 23 13:43 antony users 9431 Aug 19 18:04
Comments.odt Graphic.gif Notes.txt Slide.pdf
Dec 3rd, 2018
160
Unix Permissions
• -rw-r—– antony users 11264 Jun 23 13:45 Comments.odt
– Owner = antony
– Group = users
l Userpermissions=rw- l Grouppermissions=r– l Otherpermissions=—
– User “antony” can read and write file
– Any user in group “users” can read file
– Any other user cannot access file
Dec 3rd, 2018 161
Unix Permissions
l Execute permission
Unix filenames do not use extensions such as .exe .com .bat .pif to indicate whether they contain executable content
Execute permission bit is used to determine whether a file can be run as a program
Unix allows a program to be executed without read permission on the file
l Ausercanrunacommandbutcan’treadthefile
Dec 3rd, 2018 162
l
l
l
Permission Examples (Files)
Permission bits
Explanation
-rw-r—r–
read/write for owner, read-only for everyone else
-rw-r—–
read/write for owner, read-only for group, forbidden to others
-rwx——
read/write/execute for owner, forbidden to everyone else
-r–r–r–
read-only to everyone, including owner
-rwxrwxrwx
read/write/execute to everyone
Credits: http://cs.brown.edu/cgc/net.secbook/se01/handouts/Ch03-FilesystemSecurity.pdf
Dec 3rd, 2018 163
Permission Examples (Files)
How to stop yourself from being able to read a file which you own:
l
$ ls -l myfile
-rw-rw-rw- antony users
$ cat myfile
The contents of my file….
$ chmod u-r myfile
$ ls -l myfile –w-rw-rw- antony users $ cat myfile
cat: myfile: Permission denied
$
myfile
Dec 3rd, 2018
164
myfile
Permissions for Directories
Permissions bits interpreted differently for directories
• Read bit allows listing names of files in directory, but not their properties like size and permissions
• Write bit allows creating and deleting files within the directory
• Execute bit allows entering the directory and getting properties of files in the directory
Lines for directories in ls –l output begin with d, as below:
jk@sphere:~/test$ ls –l
Total 4
drwxr-xr-x 2 jk ugrad 4096 2005-10-13 07:37 dir1 -rw-r–r– 1 jk ugrad 0 2005-10-13 07:18 file1
Credits: http://cs.brown.edu/cgc/net.secbook/se01/handouts/Ch03-FilesystemSecurity.pdf
Dec 3rd, 2018 165
Permission Examples (Dirs)
Permission bits
Explanation
drwxr-xr-x
all can enter and list the directory, only owner can add/delete files
drwxrwx—
full access to owner and group, forbidden to others
drwx–x—
full access to owner, group can access known filenames in directory, forbidden to others
-rwxrwxrwx
full access to everyone
drwxr-xr-x
all can enter and list the directory, only owner can add/delete files
Credits: http://cs.brown.edu/cgc/net.secbook/se01/handouts/Ch03-FilesystemSecurity.pdf
Dec 3rd, 2018 166
SetUID
l Special Execute permission – SetUID
A SetUID program will execute with the privileges of its owner, no matter which user runs the command
Hence a normal user can change the contents of the ( secure ) /etc/shadow file by using the passwd command
l
l
-rw——- root root -r-s–x–x root root
/etc/shadow
/usr/bin/passwd
Dec 3rd, 2018
167
SetUID
l SetUID programs are inherently dangerous
SetUID does not necessarily mean UID 0, although this is nearly always the case
l Unixsecurityisessentially“rootornon-root”
l
l
If SetUID programs contain any vulnerabilities,
these would almost certainly result in a root
privilege exploit
l Thentheentiresecuritymodelisgone l Rootcandoanything
Dec 3rd, 2018 168
Damage Limitation
l Principle of Least Privilege
Applications should have only sufficient privilege for their needs at the time
l It’s common to have a user “nobody” under Unix
– Not allowed to log in
l Nopassword(notblank;actuallynon-existent) l Nologinshell
– Used as unprivileged user for background applications ( daemons )
l
Dec 3rd, 2018 169
Damage Limitation
l Principle of Least Privilege
Applications should have only sufficient privilege for their needs at the time
l If you use su or sudo, exit as soon as possible l SetUID utilities are especially sensitive
Background processes ( daemons ) usually have to start with root privilege
l Keepthatcodesmallandclean
l Droprootprivilegeassoonaspossible
l
l
Dec 3rd, 2018 170