CS 346 – Chapter 14

1. CS 346 – Chapter 14 • Protection (Ch. 14) • Users & processes want resources. Protection means controlling their access. • More than just RWX. • Security (Ch. 15) • Preserving integrity of system & its data

2. Background • Protect from … • Malicious, unauthorized or incompetent users • Waste (e.g. accessing expensive equipment just because cheaper resource is busy) • Distinguish between: policy & mechanism • Principle of least privilege • Minimum damage in case of error • Easier to identify who did what • Create user accounts, and tailor privileges accordingly • Bipartite relationship • Processes vs. objects • Ex. What files does a process have access to? • More practical to organize privileges by user

3. Access control matrix • Butler Lampson, 1969. • Express our policies: how subjects (users/processes) can use each object • For each subject & each object, state the access rights • Can be unwieldy in general! • Protection domain • Set of common access rights • Usually correspond to a user or class of users Ex. Students, faculty, guests, system administrators • Process runs inside a domain determined by its owner • Domains may coincidentally overlap (Figure 14.1)

4. Domains • Representation as 2-D table • Rows are the domains • Columns are objects • Entries in table specify access rights (Fig. 14.3) • A user can only be in 1 protection domain at any given time. • Static: a user/process always operates in the same domain (simple but inflexible) • Dynamic: a user/process can switch to another domain (complex but flexible) Can represent this way: domains are objects that a user in some domain can “switch” to. See Fig. 14.4. • UNIX: some programs have setuid bit set to allow domain switching.

5. Example • In addition to read/write/execute, special powers  • Copy: you can “copy” an access right for this object to another domain. • Owner: You can create/delete access rights for this object

6. Implementation • In theory, access control matrix is a huge table • Logically it’s 3 dimensional (capability is 3rd dimension) • Sparse: few rows, thousands of columns  • Waste of virtual memory, I/O to look up this separate table • Access list for objects • Each object (file or other resource) will have attribute identifying what can be done by members of each domain • Can define a default to save space • Capability list for domains • List what I have access to, and what I can do with it • We don’t want users to arbitrarily change their capabilities! Capability information must be protected. How?

7. Some questions • What should we do about objects that have no access rights defined? • How would we implement a policy limiting the number of times a resource is accessed? • How would we implement a policy allowing access only during certain times of day?

8. CS 346 – Chapter 15 • Security • Physical, human, program • Authentication • Dictionary attack • Cryptography • Defense policies

9. Areas of security Attackers look for every opportunity to get in • Physical • Restricting access: guards, locked doors • Sounds simple, but don’t neglect! • Human factors • Naivete, laziness, dishonesty • Help users pick good passwords, other recommended practices • How to handle offenders or people with a history • Program • Correct algorithm, installation of software • Used in the way originally intended • Proper behavior vs. malicious code

10. Coding errors • Not checking validation correctly • A program to support a client remotely accessing the server through commands • Input command is scrutinized for safety: limited to “safe” commands. • But if we parse the command incorrectly, we may actually perform unsafe operation unwittingly • Synchronization problem • mkdir could be executed in 2 steps: kernel creates new empty subdirectory and assigns it to root. Then, ownership is transferred to the user who executed mkdir. • In between the 2 steps: If the system is busy, evil user can execute a command to replace the new directory with a link to some other existing file on the system.

11. Malicious code • Trojan horse • 2 purposes: one obvious & benign; the other hidden and evil • Designed to appear like ordinary, beneficial program. “eat me” • Root kit • Trojans that replace system utility files • Suppose you break into a system, and install programs that allow you secret access. System admin can find evidence of your intrusion, look at system logs of your files and work. What can you do to cover your tracks? • Trap door • Flaw in a program placed there by designer. Bypasses security checks under some circumstances. May originally have been debugging mode. • Ex. Special access code

12. Malicious (2) • Virus • Fragment of code that spreads copies of itself to other programs • Requires a host program • Ex. May append/prepend its instructions to existing program • Every time program runs, virus code is executed, in order to spread itself & perhaps do other “work” • Virus scanning technique • Read program code for “signature” of known viruses. In other words, look for substring of code that is unique to the virus. • But… virus may be polymorphic • New viruses keep appearing

13. Malicious (3) • Worm • Like a virus, but it’s a stand-alone program that replicates itself and spreads. • Also can contain code to do other “work” Example: Robert Morris, 1988 • Included a special module called the “grappling hook” • Install itself on remote system • Make network connection back to original system • Transfer rest of worm to new victim • Execute worm on victim • Worm designed to exploit weaknesses in existing UNIX utility programs

14. Morris exploits • sendmail program • Debug option: allowed an e-mail message to specify a program as its recipient. This program would run, using e-mail message body as its input. • Worm created an e-mail message, containing grappling hook code…. Instructions to remove mail headers…. Resulting program passed to shell • finger daemon • Exploited buffer overflow by “fingering” a very long name. When procedure called, it overwrote correct return address with address of grappling hook code. • 2 other exploits involved remote shell applications • Attempted to crack passwords • What happened to Morris himself?

15. Dictionary attack • We can use a hash function to encode passwords • No way to compute decoded value, so we don’t have to worry about password table being compromised • Attacker’s strategy • Get the password table. Administrator complacently left it unprotected. • Compile a dictionary of thousands of common words; compute the hash value of each. • Look for matches between dictionary and values in password table. • Prepare for the threat • Ask people to pick strange passwords, or force them to use a predefined one… that’s hard to remember. • Salt the password table

16. Salt • A random string that is appended to a password before being hashed. • When user logs in, password is concatenated with salt value, hashed, and checked against entry in password table. • Attacker must now expand dictionary to contain every possible salt value with every possible password.

17. Cryptography • Generally not feasible to build a totally secure network. • Goal: secure communication over unsecure medium • Key = secret information used to encode/decode message • Recipient verifies the message it receives is from correct sender • Sender wants to ensure only the recipient will understand msg • Encryption algorithm: how to secure messages • Encryption function: (plaintext, key)  ciphertext • Decryption function: (ciphertext, key’)  plaintext • Decryption secrecy is more critical than encryption. • Types • Symmetric: Use same key; decrypt analogous to encrypt • Asymmetric: Different keys; breaking much more tedious

18. Examples • Caesar cipher; substitution ciphers • There are 26! ways in which letters can be reassigned. • What is the “key”? Is this method secure? • One-time pad (e.g. JN-25) • Dictionary table: convert each word to a 5-digit number • Additive table: add the next random number to each word • Preface the message by indicating where in additive table you are starting the encoding • Tables may be periodically changed. • Example: encryption code book.xlsx • Data encryption standard • Manipulate 64-bit chunks at a time, using XOR and shift operators.

19. RSA • Choose distinct 512-bit random primes p and q • Let N = pq, and let M = (p – 1)(q – 1) • Choose public encryption key e: a value less than and relatively prime to M. • Message is x. Sender transmits: y = xe mod N • Choose private decryption key d: where ed mod M = 1 • e and N are public; outsider should have a tough time factoring N to obtain p and q to determine d • Recipient converts: z = yd mod N which should equal x. • Example p = 31, q = 41  N = 1271, M = 1200, e = 7, d = 343 x = 12  y = 127 mod 1271 = 1047; z = 1047343 mod 1271 = 12 Note: exponentiation should not be iterative multiplications

20. Example • Choose secret primes p,q • N = pq; M = (p – 1)(q – 1) • Choose e < & relatively prime to M. • Message is x. Compute and send y = xe mod N • Pick private decrypt key d where ed mod M = 1 • z = yd mod N, which should equal x. p = 31, q = 41 N = 1271, M = 1200 e = 7 x = 12 y = 127 mod 1271 = 1047 d = 343 z = 1047343 mod 1271 = 12 It works!

21. Diffie - Hellman • Method for 2 people to establish a private key  • Choose values p (prime) and q • Sender • chooses secret value a, and computes A = qa mod p • Sends A, p, q • Eavesdropper cannot easily determine a • Receiver • Chooses secret value b • Computes B = qb mod p and K = Ab mod p • Sends B back to sender, who can compute K = Ba mod p • Both methods of computing secret K are equivalent • Ab mod p = (qa)b mod p • Ba mod p = (qb)a mod p

22. Digital signature • Used to authenticate origin of message • Also useful if later sender denies ever sending the message • Sender • Computes hash value of message  128/160 bit result • Applies D function (using private key)  “signature block” • Appends signature block to the message to send • Receiver • Applies E function (using sender’s public key)  hash • Computes hash value of message, see if there is a match. • Efficient since E & D functions applied to small amount of data. The message body itself might not be confidential.

23. Doing security • Defense in depth: don’t rely on just 1 catch-all method • Some attackers know intimate details of your system and how you operate • Attackers may make some assumptions; surprises slow them down • Penetration test. Look for: • Bad passwords • Programs that look or behave abnormally • Using setuid when not necessary • In system directory when not necessary • Too many daemons • Unusual file permissions, search paths, modification dates • Old versions of software

24. Intrusion detection • What data do you want to collect? • When is a real-time response required? • What to scan: • System calls, shell commands, network packets • Possible responses • Kill process • Surreptitiously alerting admin • Have honeypots ready for attacker • How to detect • Signature-based: look for specific string or behavior pattern • Must know what to look for • Anomalies from normal operating specifications • But, what is normal?

25. Anomaly detection • Establish accurate benchmarks of normal operation • Ex. How often do we get pinged from China? • False positive = false alarm: alert human, but no intrusion • False negative = we missed an intrusion • Deciding whether to alert human is critical, or else people will perceive a lot of false alarms exist • Example • 20 out of 1,000,000 records show intrusion • System detects/alerts 80% of these intrusion events • 16 records revealed, 4 ignored • System falsely identifies 0.01% of normal events as an intrusion • 0.01% of 999,980 = ~ 100 false alarms • From human point of view, 100/116 = 86% alarms are false