Protection and Security Sarah Diesburg Operating Systems COP 4610.
-
Upload
catherine-alannah-hutchinson -
Category
Documents
-
view
212 -
download
0
Transcript of Protection and Security Sarah Diesburg Operating Systems COP 4610.
Protection and Security
Sarah Diesburg
Operating Systems
COP 4610
Definitions
Security: policy of authorizing accesses Prevents intentional misuses of a system
Protection: the actual mechanisms implemented to enforce the specialized policy Prevents either accidental or intentional
misuses
Security Goals
Data confidentiality: secret data remains secret
Data integrity: unauthorized users should not be able to modify data
System availability: nobody can make a system unusable
Security Components
Authentication determines who the user is
Authorization determines who is allowed to do what
Enforcement makes it so people can do only what they are allowed to do
Authentication
The most common approach: passwords If I know the secret, the machine can
assume that I’m the user Problems:
1. Password storage
2. Poor passwords
Password Storage
Encryption Uses a key to transform the data Difficult to reverse without the key
UNIX stores encrypted passwords in /etc/passwd Uses one-way transformations Encrypts a typed password and
compares encrypted passwords
Poor Passwords
Short passwords Easy to crack
Long passwords Tend to be written down somewhere
Original UNIX
Required only lower-case, 5-lettered passwords
265 or 1 million combinations In 1975, it would take one day to crack
one password Today, we can go through all those
combinations < 1 second
Partial Solutions
Extend password with a unique number
Require more complex passwords 6 letters of upper, lower cases, numbers,
and special characters 706 or 100 billion combinations Unfortunately, people still pick common
words
Partial Solutions
Delay every login by 1 second Assign very long passwords
Give everyone a password calculator (credit card)
Requires a physical theft to steal the password
Authentication in Distributed Systems
Private key encryption of data Encrypt(Key, Plaintext) = Cipher text Decrypt(Key, Cipher text) = Plaintext
Hard to reverse without the key With the plaintext and the cipher text,
one cannot derive the key Provides secrecy and authentication,
as long as the key stays secret
How to distribute the keys?
Authentication server Keeps a list of keys
Kerberos Protocol
Keyxy is needed to talk between x and y
Server S
Client BClient A
KeyASKeyBS
Encrypt(KeyAS, “I want KeyAB”)
Kerberos Protocol
Keyxy is needed to talk between x and y
Server S
Client BClient A
KeyASKeyBS
Encrypt(KeyAS,“Here is KeyAB and a message to B”)
Kerberos Protocol
Keyxy is needed to talk between x and y
Server S
Client BClient A
KeyASKeyBS
messageEncrypt(KeyBS, “use KeyAB to talk to A”)
Additional Details
Expiration timestamp for a key Prevents a machine from replaying
messages (e.g., “deposit $100”) Checksum for an encrypted message
Prevents modifications to a message (e.g., “deposit $1000”)
KeyAS and KeyBS are renewed periodically to reduce their exposures
Public Key Encryption
Separates authentication from secrecy Involves a public key and private key
Encrypt(Keypublic, plaintext) = cipher text
Decrypt(Keyprivate, cipher text) = plaintext
Encrypt(Keyprivate, plaintext) = cipher text
Decrypt(Keypublic, cipher text) = plaintext
Public Key Encryption
Idea: Private key is kept secret Public key is advertised
Public Key Encryption
Encrypt(Keymy_public, “Hi, Sarah”) Anyone can create it, but only I can read
it (secrecy)
Encrypt(Keymy_private, “I’m Sarah”) Everyone can read it, but only I can
create it (authentication)
Public Key Encryption
Encrypt(Keyyour_public, Encrypt(Keymy_private,
“I know your secret”)) Only I can create it, and only you can
read it
Authorization
Access matrix describes who can do what
-The matrix tends to be sparse
File 1 Lisa’s diary File3
Bart read,write read
Lisa read, write
Maggie
Access Control List
Stores all permissions for all users with each object
Analogy: a guard in front of a door Checks for a list of people allowed to
enter UNIX: permission of each file is
specified according to its owner, group, and the world
Capability List
Stores all objects a process can touch Analogy: Keys
A key owner has the right of entry Example: page tables
Each process has a list of pages that it can access
Access Control List vs. Capability List
Access control list (commonly used) Easy to know who can access the object Hard to know which objects a user can
access Capability list
A user knows the list of objects to access Hard to know who can access an object
More difficult to revoke capabilities
Enforcement
Enforcer programs check passwords, access control lists, and so on…
In UNIX, enforcers are run as superuser
If there is a bug, you are hosed!
The State of the World in Security
Authentication Poor passwords Nobody encrypts emails
Authorization Coarse-grained access control list Often turned off for sharing
Enforcement Buggy operating systems
Classes of Security Problems
Eavesdropping is the listener approach Tap into the Ethernet and see everything Countermeasure: pressurized cabled
Abuse of privilege If the superuser is evil, there is nothing
you can do
Classes of Security Problems
Imposter breaks into the system by pretending to be someone else Recorded voice and facial image Countermeasure: behavioral
monitoring to look for suspicious activities Overwriting the boot block
Classes of Security Problems
A Trojan horse is a seemingly innocent program that performs an unexpected function Countermeasure: integrity checking
Periodically, check binaries against their checksums
Classes of Security Problems
Salami attack builds up an attack, one-bit at a time Example: send partial pennies to a bank
account Countermeasure: code reviews
Classes of Security Problems
Logic bombs: a programmer may secretly insert a piece of code into the production system A programmer feeds the system
password periodically If the programmer is fired, the logic bomb
goes off Countermeasure: code reviews
Classes of Security Problems
Denial-of-service attacks aim to reduce system availability A handful of machines can flood a victim
machine to disrupt its normal use Countermeasure: open
Pentagon Traffic Analysis
Before the 1991 Persian Gulf War Foreign intelligence tried to predict the
starting date of the war
time
Pentagon Traffic Analysis
So much for the element of surprise…
Tenex
Used to be the most popular system at universities before UNIX
Thought to be very secure
Tenex
Source code for the password check:
for (j = 0; j < 8; j++) {
if (input[j] != pw[j]) {
// go to error;
}
} Need to go through 2568 combinations
Tenex
Unfortunately, Tenex used virtual memory
A fast password check means that the first character is wrong (error)
A slow check means that the first character is correct (page fault)
password
in memory on disk
Tenex
2568 checks to crack a password is reduced down to 256 * 8 checks
The Internet Worm
In 1988, a Cornell graduate student, RTM, released a worm into the Internet
The worm used three attacks rsh fingerd sendmail
The Internet Worm
Some machines trust other machines, the use of rsh was sufficient to get into a remote machine without authentication
The Internet Worm
finger command did not check the input buffer size finger name@location Overflow the buffer Overwrite the return address of a
procedure Jump and execute a shell (under root
privilege)
The Internet Worm
sendmail allowed the worm to mail a copy of the code and get it executed
The worm was caught due to multiple infections People noticed the high CPU load