Operating System Security.

53
ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source. 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

description

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. Separation of memory. - PowerPoint PPT Presentation

Transcript of Operating System Security.

Page 1: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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

Page 2: Operating System Security.

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?

Page 3: Operating System Security.

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!

Page 4: Operating System Security.

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.

Page 5: Operating System Security.

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.

Page 6: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Figure 4-1  Fixed Fence.

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 betweenaddress 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?

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition. Image from textbook

Page 7: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Figure 4-1  Fixed Fence.

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 than640 K.

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition. Image from textbook

Page 8: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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 fixedamount 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.

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition. Image from textbook

Page 9: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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.

So far …

Page 10: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Figure 4-3  Pair of Base/Bounds Registers.

Base/Bound registers.

Every process has a base/boundRegister.Base register: contains address of theStart of a process.Bound register: address of the end of aProcess.

Even the OS now has a base bound –So the OS can be loaded into anypart of the memory – not just at address 0.

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition

Page 11: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Figure 4-3  Pair of Base/Bounds Registers.

Base/Bound registers: separate processes, but not within the process (e.g., code from

data inside a process)

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition. Image from textbook

Page 12: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Data, Program (code) registers.

Allow separation betweena program's “code” its and “data”.

Why?This prevents data from being accidentally

treated as code.

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition. Image from textbook

Page 13: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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”.

Page 14: Operating System Security.

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.

Page 15: Operating System Security.

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.

Page 16: Operating System Security.

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 inC:\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.

Page 17: Operating System Security.

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

owner

group

Page 18: Operating System Security.

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.

Page 19: Operating System Security.

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

Page 20: Operating System Security.

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.

Page 21: Operating System Security.

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.Source for this slide: Required

textbook: Security in Computing by Pfleeger and Pfleeger 4th

Edition. Image from textbook

Page 22: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Threats to passwords.

• What threats can you think of to passwords?

Page 23: Operating System Security.

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

Page 24: Operating System Security.

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

Page 25: Operating System Security.

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?

Page 26: Operating System Security.

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”.

Page 27: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Hashing Passwords/etc/passwd:

john EOINJHGHGFDJKHSDmary DKYFBHNUISHDFIUBjoe LIXBNEYGSOPDKEGF

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 behindthe hash function.

(Remember: secure hash is different from encryption/Decryption; it's one-way.)

Citation for the slide including notes: Foundations of Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 28: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Using Hashing Passwords

/etc/passwd:john EOINJHGHGFDJKHSDmary DKYFBHNUISHDFIUBjoe LIXBNEYGSOPDKEGF

“What is your username & password?”

My name is Joe. My password is automobile. Doeshash("automobile")

="LIXBNEYGSOPDKEGF

"I.e., compare hash

with the stored hash.

To check a password:(1)The login program or SSH program on the OS asks user to enter password.(2)OS then generates a hash value of the

entered password.(3) OS compares this hash value with that inthe password file. If they match – login else teject.

Citation for the slide including notes: Foundations of Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 29: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Off-line Dictionary Attack on stored hashes of passwords.

h("automobile") = "LIXBNEYGSOPDKEGF"h("aardvark") = "DOPIDFKMOSIHFDXS"h("balloon") = "DKYFBHNUISHDFIUB"h("doughnut") = "DKLJDFUISNHDFKUJ"

/etc/passwd:john EOINJHGHGFDJKHSDmary DKYFBHNUISHDFIUBjoe LIXBNEYGSOPDKEGF

STEP 1: Attacker Obtains Password File:

STEP 2: Attacker computes possible password hashes(using words from dictionary)

Hashing passwords makes it harder to use a passwd file, but easy passwords can still be broken! Here’s an

example.

Citation for the slide including notes: Foundations of Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 30: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Off-line Dictionary Attack on stored hashes of passwords (2).

h("automobile")= "LIXBNEYGSOPDKEGF"h("aardvark") = "DOPIDFKMOSIHFDXS"

h("balloon") = "DKYFBHNUISHDFIUB"h("doughnut") = "DKLJDFUISNHDFKUJ"

/etc/passwd:john EOINJHGHGFDJKHSD

mary DKYFBHNUISHDFIUBjoe LIXBNEYGSOPDKEGF

Attacker computes possible password hashes(using words from dictionary)

Step 3: Attacker determines thatMary’s password is “balloon!”

Source for the slide: Foundations of Security: What Every Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 31: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Off-line Dictionary Attack on stored hashes of passwords (3).

h("automobile") = "LIXBNEYGSOPDKEGF"h("aardvark") = "DOPIDFKMOSIHFDXS"h("balloon") = "DKYFBHNUISHDFIUB"h("doughnut") = "DKLJDFUISNHDFKUJ"

Computing the hash values of every word in a dictionary is time-consuming. So attackers pre-compute 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

Page 32: Operating System Security.

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

Page 33: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Salting Hashed Passwords

/etc/passwd:john LPINSFRABXJYWONF 2975mary DOIIDBQBZIDRWNKG 1487joe LDHNSUNELDUALKDY 2764

“What is your username & password?”My name is Joe. My password is automobile.

Doesh("automobile2764")

="LDHNSUNELDUALKDY"

???

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.

When checking password – the salt is read from the password file

and concatenated with the passwordbefore hashing.

How does this help?

Citation for the slide including notes: Foundations of Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 34: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Off-line Dictionary Foiled (or made harder)!

h(automobile0001) = KNVXKOHBDEBKOURXh(automobile0002) = ZNBXLPOEWNVDEJOGh(automobile0003) = ZMCXOSJNFKOFJHKDFh(automobile0004) = DJKOINSLOKDKOLJUS

…h(aardvark0001) = DKOUOXKOUDJWOIQh(aardvark0002) = PODNJUIHDJSHYEJNU

…Etc…

Too many combinations!!!

Attack is Foiled!

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 automobileand salt value is 2764, then what the OS actually stores on the disk is hash(automobile2764). To use a pre-computed dictionary,attacker now not only has to pre-compute hash(automobile) but actually hash(automobile1), hash(automobile2) …. Etc... So basically, number of things to pre-compute has been increased, drastically. By how much – next slide example

Citation for the slide including notes: Foundations of Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 35: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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) = DKYFBHNUISHDFIUB3. 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 Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 36: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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 Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 37: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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.

Page 38: Operating System Security.

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

non-root 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 Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 39: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Password Security• Can you think of other techniques to

make passwords harder to crack?

Page 40: Operating System Security.

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 Security: What Every

Programmer Needs to Know by Neil Daswani et.al, ISBN:  978-1590597842

Page 41: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Figure 4-15  Users’ Password Choices.Source for this slide: Required

textbook: Security in Computing by Pfleeger and Pfleeger 4th

Edition. Image from textbook

Page 42: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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.

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition. Image from textbook

Page 43: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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…

Page 44: Operating System Security.

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

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition. Image from textbook

Page 45: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

After authentication, comes authorization.

• After OSes authenticate they authorize the user.– Use the user ids to control access to

objects (Access control).

Source for this slide: Required textbook: Security in Computing

by Pfleeger and Pfleeger 4th Edition. Image from textbook

Page 46: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

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).

Page 47: Operating System Security.

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.

Page 48: Operating System Security.

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?

Page 49: Operating System Security.

ITEC 345: Material mainly derived from Pfleeger; Daswani or Stallings (all recommended books). See the yellow box for the exact source.

Authorization (3)• Simple ACLUser Resource PrivilegeAlice C:\My Documents\Alice read,

writeBob C:\My Documents\Bob read, write,

execute

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:\SecurityDocsread, write

Page 50: Operating System Security.

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).

Page 51: Operating System Security.

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.

Page 52: Operating System Security.

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?

Page 53: Operating System Security.

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?