Operating System Security.
• Previous topic: Application security
• Now: Use operating system as
example for application security.
– Overview of security provided by the
operating system in accessing:
• Memory
• Files
• Processes
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Separation of memory.
• The first resource that we will study
is the memory. How does the OS
protect the memory of one process
from another?
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Resource: Memory – Which OSes provide
memory separation (2)
•
Memory separation is provided in the following OSes:
– Windows NT and above.
– UNIX, Linux, Mac OS X
• Windows 9x family did not provide any separation  a
user level program could access and modify the
operating system memory!
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Resource: Memory – What security issues
are involved?
•
Memory is used by:
– The Operating System (OS)
– Processes that are running on the OS
• Separation is therefore needed:
– Between the OS and all the other processes.
• E.g., user processes should not be able to overwrite or change the
OS.
• This is crucial! Why? An OS provides several security
mechanisms (e.g., login, permissions on files etc.).
• It is critical that these mechanisms cannot be tampered with
by a regular user run program!
– Between processes.
• Between processes of the same user. E.g., a Word process should
not interfere with Chrome (even if the same user is running both).
• Also, between processes of different users.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Next:
Separating memory between OS and all
the other processes.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Separating memory between OS and other procesess:
First option: limiting the hardware address.
Architectures can “designate” a
certain/fixed memory address, called
“fence”. An OS is always stored between
address 0 and the fence (e.g., n in the
figure).
Example: intel 386 and before:
Fence used to be: 640K.
Hence, an OS had to fit between
0 and 640 K.
Any issues?
Figure 4-1 Fixed Fence.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger
Pfleeger and
and Pfleeger
Pfleeger 44thth Edition.
Edition
Image from textbook
Separating memory between OS and other procesess:
Problems with the first option: limiting the
hardware address.
Issues with a fixed fence:
Limits the size of the OS. (E.g.,
In intex 286, the OS had to be
640 K or less). MS-DOS was less than
640 K.
Figure 4-1 Fixed Fence.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger
Pfleeger and
and Pfleeger
Pfleeger 44thth Edition.
Edition
Image from textbook
Separating memory: Second solution: allow
“fence” to be determined by OS by
designating a “register” as a fence register
(address limit register).
What’s a register?
Every architecture (intel etc..)
has a fixed
amount of memory in their
CPU’s – these are called registers.
They are faster to access than cache or RAM.
Figure 4-2 Variable Fence Register.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger
Pfleeger and
and Pfleeger
Pfleeger 44thth Edition.
Edition
Image from textbook
So far …
We saw: how to separate an OS from the rest of the
processes using a “fence register”. However, this
won’t separating one process from the other. It is
limited to only separating an OS from other
processes.
Solution: use of a pair of registers called
“base/bound” for each process.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Base/Bound registers.
Every process has a base/bound
Register.
Base register: contains address of the
Start of a process.
Bound register: address of the end of a
Process.
Even the OS now has a base bound –
So the OS can be loaded into any
part of the memory – not just at
address 0.
Figure 4-3 Pair of Base/Bounds Registers.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger and Pfleeger 4th Edition
Base/Bound registers: separate processes,
but not within the process (e.g., code from
data inside a process)
Figure 4-3 Pair of Base/Bounds Registers.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger and Pfleeger 4th Edition.
Image from textbook
Data, Program (code) registers.
Allow separation between
a program's “code” its and “data”.
Why?
This prevents data from being accidentally
treated as code.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger and Pfleeger 4th Edition.
Image from textbook
Summary so far …
1. Memory fence separates OS,user memory.
2. base/bound registers separate process mem.
3. Data/Code segment registers separate data
and code within a process.
4. Finally: Within a process, some data is “read
only” (e.g., finals/constants in a program).
This is achieved using a “tagged architecture”.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Protecting other objects.
• Protecting memory is easy:
– The hardware provides registers that can be used as fences.
• Whenever a process accesses memory, the memory address it is
seeking can be checked with the register value.
– Illegal accesses can be flagged.
– There is only one way to access memory – through hardware.
– Hence, the OS is able to completely mediate access to memory.
• But protecting other objects (e.g., files, passwords,
directory of files, a hardware device) is not so easy:
– First the access may not be just read, write or execute.
– The number of ways to access a particular object maybe
several. E.g., a file can be accessed by using the OS – or simply
by removing the disk and attaching it to another machine.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
UserIDs and Group IDs
•
In order to separate: the OS must first need to identify users. It
does this:
– By authentication (e.g., using passwords).
– After authentication the user becomes a number on the system: called
user id.
•
In all GPOSes (general purpose Operating Systems), every user has a
specific unique user id.
–
–
The administrator (also called root in UNIX) has a user id of 0.
Exercise in class: access the “/etc/passwd” file in UNIX to see the userids.
•
When a user logs in, every program executed by the user starts running
with the user id of that user.
•
The same userid is used as part of the Access control list to assign
permissions to resources.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
UserIds and GroupIDs.
• User Ids, Group Ids are often stored in
/etc/passwd or in
C:\Windows\system32\config\SAM
• An example entry from /etc/passwd file:
root:*:0:0:System Administrator:/var/root:/bin/sh
• Windows/UNIX access control policy: A program running
with a specific user id can access (read, write, or execute)
any resource which that specific user id is permitted to
access.
• E.g., if a root is editing a document in Microsoft Word. That
same process MS Word can be used to open and edit, say,
the password file.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
UserIDs and Group IDs
• Example:
– Consider a file in a GPOS with associated permissions in
UNIX/Linux (simply run “ls -lt” to obtain this output).
– If a user Alice logs into the computer, can she:
• Open the file passwd in program MS word for reading?
• Open the file passwd in program MS word for writing?
A program can only access a resource if the user executing the
program has permissions to access that resource.
-rw-r--r-- 1 root wheel 1932 Jan 13 2006 /etc/passwd
Permissions:
User can read/write;
Group can read;
Others can read
group
owner .
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
Summary
• We have seen how OSes protect
memory.
• Next:
– How to protect other objects (other
than memory)?
• Authenticating users: passwords.
• File system protection and access control.
• Types of access control.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Minding our language …
• Permissions: access rights associated with a
resource. E.g., “read” permission on a file.
• Privileges: access rights given to a program to do a
task. E.g., Does MS word executed by Bob has the
permissions to write into Alice’s folder?
• Both permissions and privileges almost mean the
same. But sometimes are different.
• Administrator = root = superuser = wheel = admin
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Goals in protecting objects.
• To protect an object such as a file,
we need mechanisms that satisfy
these goals:
– Check every access (called the principle
of complete mediation).
– Enforce least privilege (principle of least
privilege).
– Verify acceptable usage .
• Next: looking at some of the OS mechanisms that
provide these features.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Next: Authenticating identity.
The concept of passwords.
• Authentication is usually based on one
or more of the following:
– Something you know. E.g. PIN
– Something you have. E.g., card.
– Something you are. E.g., Fingerprint.
• Usually a good system will require atleast two or more of the
above ways of authentication (called 2 point authentication).
– This is an example of the principle of separation of
privileges.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger and Pfleeger 4th Edition.
Image from textbook
Threats to passwords.
• What threats can you think of to
passwords?
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Password Security
• Many applications use login names and passwords
• Password systems are vulnerable to attack
• Early password security studies (1979)
– Morris, Thompson:
86% of user passwords could be cracked
• Threat:
– Dictionary Attacks – attacks where dictionary is used to guess
passwords.
– Reading the passwords from the disk. E.g., user copies the
password file and then tries to crack passwords.
• Next: OS mechanisms to protect against these
threats.
Citation for the slide including notes: Foundations of
.
Security: What Every Programmer Needs to Know
by Neil Daswani et.al, ISBN: 978-1590597842
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
Password Security
• Approaches (we will study each of these …):
– make password file non-readable by all users (e.g.,
shadow passwords in UNIX and Windows)
– Do not store the passwords on disk – instead store their
secure hashes.
– Use “salt” with passwords to make it harder to guess.
Citation for the slide including notes: Foundations of
.
Security:
What Every Programmer Needs to Know
by Neil Daswani et.al, ISBN: 978-1590597842
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
Password security and use of secure hash
functions.
• Passwords need to be stored on the
disk.
• The first passwords were stored in
clear text – is this a good idea?
• One solution is to “encrypt” the
password using a symmetric key
cipher (e.g., DES). Why is this not
a great idea?
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Password security and use of secure hash
functions (2).
• One solution is to “encrypt” the password using a symmetric
or public key cipher (e.g., DES or RSA). Why is this not a
great idea?
• Symmetric or asymmetric (public) ciphers use a secret
key or a private key. Where can the OS store this
private key?
• So now the problem is: how to store the secret key used
in encryption? Storing that in clear text is not a good
idea either. Encrypting it is not a great idea either –
because to encrypt you will need another secret key. How
to store this new secret key – This becomes a major
problem.
• Solution: Use secure hash functions. Secure hash functions
do not require a “secret key”.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Hashing Passwords
Instead of storing the actual
password on disk –
UNIX/Linux/Windows/Mac OS store a
“secure hash”
of the password. Remember, if someone
gets a hash they cannot get the original
input. This was one of the conditions behind
the hash function.
john
mary
joe
/etc/passwd:
EOINJHGHGFDJKHSD
DKYFBHNUISHDFIUB
LIXBNEYGSOPDKEGF
(Remember:
secure hash is different from encryption/
Decryption; it's one-way.)
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Using Hashing Passwords
“What is your username & password?”
Does
My name is Joe. My password is automobile. hash("automobile")
=
"LIXBNEYGSOPDKEGF"
I.e., compare hash with
To check a password:
the stored hash.
(1) The login program or SSH program on the
OS asks user to enter password.
(1) OS then generates a hash value of the
entered password.
/etc/passwd:
(3) OS compares this hash value with that in
john
EOINJHGHGFDJKHSD
the password file. If they match – login else
teject.
mary
DKYFBHNUISHDFIUB
joe
LIXBNEYGSOPDKEGF
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Off-line Dictionary Attack on stored
hashes of passwords.
Hashing passwords makes it harder to use a passwd file, but
easy passwords can still be broken! Here’s an example.
STEP 1: Attacker Obtains
Password File:
john
mary
joe
/etc/passwd:
EOINJHGHGFDJKHSD
DKYFBHNUISHDFIUB
LIXBNEYGSOPDKEGF
STEP 2: Attacker computes possible password hashes
(using words from dictionary)
h("automobile")
h("aardvark")
h("balloon")
h("doughnut")
= "LIXBNEYGSOPDKEGF"
= "DOPIDFKMOSIHFDXS"
= "DKYFBHNUISHDFIUB"
= "DKLJDFUISNHDFKUJ"
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Off-line Dictionary Attack on stored
hashes of passwords (2).
john
mary
joe
/etc/passwd:
EOINJHGHGFDJKHSD
DKYFBHNUISHDFIUB
LIXBNEYGSOPDKEGF
Step 3: Attacker determines that
Mary’s password is “balloon!”
Attacker computes possible password hashes
(using words from dictionary)
h("automobile") = "LIXBNEYGSOPDKEGF"
h("aardvark")
= "DOPIDFKMOSIHFDXS"
h("balloon")
= "DKYFBHNUISHDFIUB"
h("doughnut")
= "DKLJDFUISNHDFKUJ"
Source for the slide: Foundations of Security: What
.
Every Programmer Needs to Know by Neil Daswani
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
et.al, ISBN: 978-1590597842
Off-line Dictionary Attack on stored
hashes of passwords (3).
h("automobile")
h("aardvark")
h("balloon")
h("doughnut")
=
=
=
=
"LIXBNEYGSOPDKEGF"
"DOPIDFKMOSIHFDXS"
"DKYFBHNUISHDFIUB"
"DKLJDFUISNHDFKUJ"
Computing the hash values of every word in a
dictionary is time-consuming. So attackers precompute a file with every word and its hash.
Then, sort this file by the hashes; looking up
whether a hash happens to be a hash of a dictionary
word is now a binary search (fast).
Then, if they gain access to a list of hashed
passwords, it is quick to look at each one and see if
it's the hash of a dictionary word. Very fast.
Source for the slide: Foundations of Security: What
Every Programmer Needs to Know by Neil Daswani
et.al, ISBN: 978-1590597842
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
How to prevent off-line dictionary
attacks?
• Not too many choices…cannot be easily
prevented.
• However, a small pseudo random number
known as “salt” helps a bit when the attacker
uses “pre-computed” hashes on dictionary.
– Recall: we said
1.
It is time-consuming for an attacker to hash every
dictionary word when breaking a password.
2. So attacker pre-computes hashes and sorts, reusing
them everytime he/she has to crack passwords .
The goal of adding salt to hashes is to make a
pre-computed hash of a dictionary worthless.
Source for the slide: Foundations of Security: What
.
Every Programmer Needs to Know by Neil Daswani
et.al, ISBN: 978-1590597842
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
Salting Hashed Passwords
john
mary
joe
/etc/passwd:
LPINSFRABXJYWONF
DOIIDBQBZIDRWNKG
LDHNSUNELDUALKDY
2975
1487
2764
“What is your username & password?”
Along with each password,
UNIX/Windows
stores a “salt” value –
a pseudo random number.
E.g., “joe”’s password salt:
2764.
The salt is different for each user.
My name is Joe. My password is automobile.
Does
h("automobile2764")
=
"LDHNSUNELDUALKDY"
???
When checking password – the
salt is read from the password file
and concatenated with the password
before hashing.
How does this help?
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Off-line Dictionary Foiled (or made
harder)!
h(automobile0001) = KNVXKOHBDEBKOURX
h(automobile0002) = ZNBXLPOEWNVDEJOG
h(automobile0003) = ZMCXOSJNFKOFJHKDF
h(automobile0004) = DJKOINSLOKDKOLJUS
…
h(aardvark0001) = DKOUOXKOUDJWOIQ
h(aardvark0002) = PODNJUIHDJSHYEJNU
…Etc…
Assume attacker wants to use pre-computed hashes of a
Dictionary. To pre-compute the attacker needs to hash both
a dictionary word and a salt: E.g., if Joe’s password is automobile
and salt value is 2764, then what the OS actually stores on the
disk is hash(automobile2764). To use a pre-computed dictionary,
Too manybut
attacker now not only has to pre-compute hash(automobile)
actually hash(automobile1), hash(automobile2) combinations!!!
…. Etc...
Attack
is
So basically, number of things to pre-compute has been
increased,
Foiled!
drastically. By how much – next slide example
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Off-line Dictionary Foiled (or made
harder)!
Consider a simple example – let us say password of Joe is a
dictionary word from the Merriam-Webster dictionary.
1. Now: Assume this dictionary has 470000 words.
2. Let,
• Joe’s password be: “automobile”
• hash of this be: h(automobile) = LIXBNEYGSOPDKEGF
• Mary’s password be: “balloon”
• hash of this be: h(vehicle) = DKYFBHNUISHDFIUB
3. Now, to break this in an offline attack – the attacker does the
following:
1. PRE-COMPUTE Go through the entire dictionary and compute
hash of each word.
2. For both Joe and Mary, do a reverse look-up of the hashes
LIXBNEYGO… and DKYFB… and obtain the passwords.
Next: Let us see how a salt can make this harder.
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Off-line Dictionary Foiled (or made
harder)!
Assume a salt can be a max of 4 digits (e.g., 1000 or 1001).
1. Now: Assume that dictionary has 470000 words.
2. Let,
• Joe’s password be: “automobile”; Let salt for Joe be: 2764
• hash of this: h(automobile2764) = LIXBNEYGSOPDKEGF
•
Mary’s password be: “balloon”; Let salt for Mary be: 1001
• hash of this be: h(balloon2764) = DKYFBHNUISHDFIUB
3. Now, to break this in an offline attack – the attacker does the following:
1. PRE-COMPUTE Go through the entire dictionary and compute hash of
each word. However this won’t work – because now the hash that
the attacker has to reverse lookup is the word + salt.
2. Hence, attacker has to pre-compute for each word in the dictionary:
1. Hash (word + each possible salt).
1. With 4 digits, 10000 salts are possible (0000 to 9999). Hence, for
each word 10000 more pre-computations.
2.  for 470000 words, pre-computation now requires: 470000 *
10000 computations!
So! A salt increased the difficulty of pre-computation by 10000 times!
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Where Salt is not useful.
• Salt is useful:
– If attacker is using pre-computed dictionary
words.
• But if attacker computes on the fly – the attackers
code can easily read the “salt” value and then find
hash. These days, doing this is not computationally
challenging.
– If attacker is running an “online” brute-force
attack.
• E.g., trying to guess the password on gmail online
account by trying out various combos.
• Doesn’t matter if salt is used…as one combo may
work.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
More Password Security
• Shadow Passwords
– Make password file inaccessible to nonroot users in /etc/shadow
• “Booby-traps” (guest/guest) – keep
an easy to break account so attacker
doesn’t try other accounts (doesn’t
work).
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Password Security
• Can you think of other techniques to make
passwords harder to crack?
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Password Security: some solutions to make
attacks harder
• Other Tools / Techniques for good password
security:
–
–
–
–
–
Strong Password Suggestions
Password Filtering
Aging Passwords
Pronounceable Passwords
Limited Login Attempts / Acct Locking (
• E.g., using captchas – these are the human readable but
machine unreadable words or images that are displayed
when you make too many wrong login attempts)
– Artificial Delays
– Display Last Date, Time, & Location
– User Education
Citation for the slide including notes: Foundations of
.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
Security: What Every Programmer Needs to Know
See the yellow box for the exact source.
by Neil Daswani et.al, ISBN: 978-1590597842
Figure 4-15 Users’ Password Choices.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger and Pfleeger 4th Edition.
Image from textbook
Another security mechanism: One-time
Passwords
• Uses a password-generating device.
• Can be integrated into a PDA, cell
phone, or other mobile device
• A password cannot be used more than
once…user has a list of all passwords
with the help of a device.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger and Pfleeger 4th Edition.
Image from textbook
Password guessing software.
• A good technique to ensure passwords
by users are secure is to simply try
and crack them (if you are a system
admin with the privileges to do this).
• Software tools are available.
– Cain and Abel – very powerful password
cracker for Windows.
– Aircrack
– John the ripper
– Etc…
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Password Security: Summary
•
•
•
•
•
•
Hashing passwords
Dictionary Attacks
Salting
Enhancements
One-time Passwords
Password Guessers
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger and Pfleeger 4th Edition.
Image from textbook
After authentication, comes authorization.
• After OSes authenticate they
authorize the user.
– Use the user ids to control access to
objects (Access control).
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Source for this slide: Required
textbook: Security in Computing by
Pfleeger and Pfleeger 4th Edition.
Image from textbook
Authorization.
• There are various ways to authorize.
• They all fall under the area of
“access control”, i.e., controlling the
access to a certain object (e.g., a
file).
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Authorization
• Authorization can range from simple rules
to very complex fine-grained rules.
• Examples:
– Simple rules:
• User ABC can only access files in folder C:/
• User ABC cannot execute any program for more than
20 minutes.
– Complex rules:
• Military/secret agency situations: The Vice-President
can read information about a secret agent and can
share that information with her/his Chief of Staff,
but not with the Press and only some members of
Congress.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Authorization (2)
•
Authorization in Operating Systems
–
–
Most OSes (Windows, Linux) maintains a data structure
(list) called Access Control List (ACL).
ACLs contain a list of users, the resources each user can
access, and the set of permissions with which the user
can access the resources.
–
E.g, consider a file in the following folder:
C:\Document and Settings\Bob\493Project.doc
The OS maintains the following information:
(1) Which user can access the file 493Project.doc
E.g., can Bob access the file?
(2) In what way can Bob access the file?
E.g., can he read the file, change the contents (write) of the
file or both? Can he even see the last-changed date?
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Authorization (3)
• Simple ACL
User
Alice
Bob
execute
Resource
C:\My Documents\Alice
C:\My Documents\Bob
Privilege
read, write
read, write,
Most Operating systems also assign “roles” or group users.
E.g.,
Bob
Student, SecurityGroup // Alice belongs to Student and
Security group.
Alice
Faculty, SecurityGroup.
Then an ACL such as this will give same permissions to both Bob and
Alice:
SecurityGroup C:\SecurityDocs read, write
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Access Control Models
• Access control models
Consider the following two scenarios:
– Scenario 1: In a University where computers are public and accessed by many
people. There are many students and the student body is a rotating population
(I.e., students graduate). Assume student Bob writes a song in a file.
Should Bob be able to share the song with whomever he wants to?
–
Scenario 2: A spy, Alice, creates a secret document about a country’s intention to
acquire high protein tomatoes. Now,
Should Alice be able to share the info on the tomatoes with whomever she wants to?
In both scenarios, Alice and Bob were the ones who created the file.
However, their ability to assign permissions is different.
To capture such different scenarios we use what are called
Access Control models (What are the different ways to
control access to files).
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Access control models
• The most commonly used model is called discretionary access
control model (or DAC for short).
DAC controls access as follows:
The user creating a resource is its owner.
The owner determines the authorized users of that
resource.
E.g., when Bob creates a file, Bob can determine who can
access that file.
– This is the model on all general purpose Operating
Systems (OSs) such as Windows, Linux.
• Exercise: Take any existing file on Linux and set
its permissions to read only.
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Access Control Models (2)
• Mandatory Access Control (MAC)
An “administrator” determines
authorizations.
Hence, a person who creates a resource is
not the owner of the resource and does not
determine the authorizations.
Can you think of situations where such a
model is applicable?
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.
Role-based access control (RBAC)
• RBAC is a twist on MAC.
– Like MAC, the administrator determines authorizations
– Every user is assigned different roles. A user is logged into one role at
any given time.
– Authorizations are given to roles.
• E.g., consider a faculty member. She/he can be (at the same
time):
– Head of the department
– Professor
– Advisor to an ACM student club.
• In RBAC each of the three roles is assigned different
authorizations. E.g., Head of the Department can access
transcripts of all students. However, Advisor to ACM cannot.
• Exercise: how will you implement RBAC on Linux?
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books)
See the yellow box for the exact source.
.