Post on 07-Oct-2020
Chapter 9: Security
Chapter 9: Security 2CMPS 111, UC Santa Cruz
Security
The security environment Basics of cryptography User authentication Attacks from inside the system Attacks from outside the system Protection mechanisms Trusted systems
Chapter 9: Security 3CMPS 111, UC Santa Cruz
Security environment: threats
Operating systems have goalsConfidentialityIntegrityAvailability
Someone attempts to subvert the goalsFunCommercial gain
Denial of serviceSystem availability
Tampering with dataData integrity
Exposure of dataData confidentiality
ThreatGoal
Chapter 9: Security 4CMPS 111, UC Santa Cruz
What kinds of intruders are there?
Casual prying by nontechnical usersCuriosity
Snooping by insidersOften motivated by curiosity or money
Determined attempt to make moneyMay not even be an insider
Commercial or military espionageThis is very big business!
Chapter 9: Security 5CMPS 111, UC Santa Cruz
Accidents cause problems, too…
Acts of GodFiresEarthquakesWars (is this really an “act of God”?)
Hardware or software errorCPU malfunctionDisk crashProgram bugs (hundreds of bugs found in the most recent Linux kernel)
Human errorsData entryWrong tape mountedrm * .o
Chapter 9: Security 6CMPS 111, UC Santa Cruz
Cryptography
Goal: keep information from those who aren’t supposed to see it
Do this by “scrambling” the data
Use a well-known algorithm to scramble dataAlgorithm has two inputs: data & keyKey is known only to “authorized” usersRelying upon the secrecy of the algorithm is a very bad idea (see WW2 Enigma for an example…)
Cracking codes is very difficult, Sneakers and other movies notwithstanding
Chapter 9: Security 7CMPS 111, UC Santa Cruz
Cryptography basics
E DC=E(P,KE)
P P
KE KD
Ciphertext PlaintextPlaintext
Encryption Decryption
Encryptionkey
Decryptionkey
Algorithms (E, D) are widely knownKeys (KE, KD) may be less widely distributedFor this to be effective, the ciphertext should be the only information that’s available to the worldPlaintext is known only to the people with the keys (in an ideal world…)
Chapter 9: Security 8CMPS 111, UC Santa Cruz
Secret-key encryption
Also called symmetric-key encryptionMonoalphabetic substitution
Each letter replaced by different letter
Vignere cipherUse a multi-character keyTHEMESSAGEELMELMELMEXSQQPEWLSI
Both are easy to break!Given the encryption key, easy to generate the decryption keyAlternatively, use different (but similar) algorithms for encryption and decryption
Chapter 9: Security 9CMPS 111, UC Santa Cruz
Modern encryption algorithms
Data Encryption Standard (DES)Uses 56-bit keysSame key is used to encrypt & decryptKeys used to be difficult to guess
Needed to try 255 different keys, on averageModern computers can try millions of keys per second with special hardwareFor $250K, EFF built a machine that broke DES quickly
Current algorithms (AES, Blowfish) use 128 bit keysAdding one bit to the key makes it twice as hard to guessMust try 2127 keys, on average, to find the right oneAt 1015 keys per second, this would require over 1021
seconds, or 1000 billion years!Modern encryption isn’t usually broken by brute force…
Chapter 9: Security 10CMPS 111, UC Santa Cruz
Unbreakable codes
There is such a thing as an unbreakable code: one-time padUse a truly random key as long as the message to be encodedXOR the message with the key a bit at a time
Code is unbreakable becauseKey could be anythingWithout knowing key, message could be anything with the correct number of bits in it
Difficulty: distributing key is as hard as distributing messageDifficulty: generating truly random bits
Can’t use computer random number generator!May use physical processes
Radioactive decayLeaky diodeLava lamp (!) [http://www.sciencenews.org/20010505/mathtrek.asp]
Chapter 9: Security 11CMPS 111, UC Santa Cruz
Public-key cryptography
Instead of using a single shared secret, keys come in pairs
One key of each pair distributed widely (public key), Kp
One key of each pair kept secret (private or secret key), Ks
Two keys are inverses of one another, but not identicalEncryption & decryption are the same algorithm, soE(Kp,E(Ks,M) = E(Ks,E(Kp,M) = M
Currently, most popular method involves primes and exponentiation
Difficult to crack unless large numbers can be factoredVery slow for large messages
Chapter 9: Security 12CMPS 111, UC Santa Cruz
The RSA algorithm for public key encryption
Public, private key pair consists of Kp = (d,n) Ks = (e,n) n = p x q (p and q are large primes)d is a randomly chosen integer with GCD (d, (p-1) x (q-1)) = 1e is an integer such that (e x d) MOD (p-1) x (q-1) = 1
p & q aren’t published, and it’s hard to find them: factoring large numbers is thought to be NP-hardPublic key is published, and can be used by anyone to send a message to the private key’s ownerEncryption & decryption are the same algorithm:E(Kp,M) = Md MOD n (similar for Ks)
Methods exist for doing the above calculation quickly, but...Exponentiation is still very slowPublic key encryption not usually done with large messages
Chapter 9: Security 13CMPS 111, UC Santa Cruz
One-way functions
Function such thatGiven formula for f(x), easy to evaluate y = f(x)Given y, computationally infeasible to find any x such that y = f(x)
Often, operate similar to encryption algorithmsProduce fixed-length output rather than variable length outputSimilar to XOR-ing blocks of ciphertext together
Common algorithms includeMD5: 128-bit resultSHA-1: 160-bit result
Chapter 9: Security 14CMPS 111, UC Santa Cruz
Digital signatures
Digital signature computed byApplying one-way hash function to original documentEncrypting result with sender’s private key
Receiver can verify byApplying one-way hash function to received documentDecrypting signature using sender’s public keyComparing the two results: equality means document unmodified
Originaldocument
Hash
One-wayhashfunction Digital
signature
Hash resultencryptedwith Ks
Originaldocument
DigitalsignatureReceiver gets
Chapter 9: Security 15CMPS 111, UC Santa Cruz
Pretty Good Privacy (PGP)
Uses public key encryptionFacilitates key distributionAllows messages to be sent encrypted to a person (encrypt with person’s public key)Allows person to send message that must have come from her (encrypt with person’s private key)
Problem: public key encryption is very slowSolution: use public key encryption to exchange a shared key
Shared key is relatively short (~128 bits)Message encrypted using symmetric key encryption
PGP can also be used to authenticate senderUse digital signature and send message as plaintext
Chapter 9: Security 16CMPS 111, UC Santa Cruz
User authentication
Problem: how does the computer know who you are?Solution: use authentication to identify
Something the user knowsSomething the user hasSomething the user is
This must be done before user can use the systemImportant: from the computer’s point of view…
Anyone who can duplicate your ID is youFooling a computer isn’t all that hard…
Chapter 9: Security 17CMPS 111, UC Santa Cruz
Authentication using passwords
Successful login lets the user inIf things don’t go so well…
Login rejected after name enteredLogin rejected after name and incorrect password entered
Don’t notify the user of incorrect user name until after the password is entered!
Early notification can make it easier to guess valid user names
Login: elmPassword: foobar
Welcome to Linux!
Login: jimpUser not found!
Login:
Login: elmPassword: barfleInvalid password!
Login:
Chapter 9: Security 18CMPS 111, UC Santa Cruz
Dealing with passwords
Passwords should be memorableUsers shouldn’t need to write them down!Users should be able to recall them easily
Passwords shouldn’t be stored “in the clear”Password file is often readable by all system users!Password must be checked against entry in this file
Solution: use hashing to hide “real” passwordOne-way function converting password to meaningless string of digits (Unix password hash, MD5, SHA-1)Difficult to find another password that hashes to the same random-looking stringKnowing the hashed value and hash function gives no clue to the original password
Chapter 9: Security 19CMPS 111, UC Santa Cruz
Salting the passwords
Passwords can be guessedHackers can get a copy of the password fileRun through dictionary words and names
Hash each nameLook for a match in the file
Solution: use “salt”Random characters added to the password before hashingSalt characters stored “in the clear”Increase the number of possible hash values for a given password
Actual password is “pass”Salt = “aa” => hash “passaa”Salt = “bb” => hash “passbb”
Result: cracker has to try many more combinations
Mmmm, salted passwords!
Chapter 9: Security 20CMPS 111, UC Santa Cruz
Sample breakin (from LBL)
LBL> telnet elxsiELXSI AT LBLLOGIN: rootPASSWORD: rootINCORRECT PASSWORD, TRY AGAINLOGIN: guestPASSWORD: guestINCORRECT PASSWORD, TRY AGAINLOGIN: uucpPASSWORD: uucpWELCOME TO THE ELXSI COMPUTER AT LBL
Moral: change all the default system passwords!
Chapter 9: Security 21CMPS 111, UC Santa Cruz
Authentication using a physical object
Magnetic cardStores a password encoded in the magnetic stripAllows for longer, harder to memorize passwords
Smart cardCard has secret encoded on it, but not externally readableRemote computer issues challenge to the smart cardSmart card computes the response and proves it knows the secret
Chapter 9: Security 22CMPS 111, UC Santa Cruz
Authentication using biometrics
Use basic body properties to prove identityExamples include
FingerprintsVoiceHand sizeRetina patternsIris patternsFacial features
Potential problemsDuplicating the measurementStealing it from its original owner?
Chapter 9: Security 23CMPS 111, UC Santa Cruz
Countermeasures
Limiting times when someone can log inAutomatic callback at number prespecified
Can be hard to use unless there’s a modem involved
Limited number of login triesPrevents attackers from trying lots of combinations quickly
A database of all loginsSimple login name/password as a trap
Security personnel notified when attacker bitesVariation: allow anyone to “log in,” but don’t let intruders do anything useful
Chapter 9: Security 24CMPS 111, UC Santa Cruz
Attacks on computer systems
Trojan horsesLogic bombsTrap doorsVirusesExploiting bugs in OS code
Chapter 9: Security 25CMPS 111, UC Santa Cruz
Trojan horses
Free program made available to unsuspecting userActually contains code to do harmMay do something useful as well…
Altered version of utility program on victim's computerTrick user into running that program
Example (getting superuser access on CATS?)Place a file called ls in your home directory
File creates a shell in /tmp with privileges of whoever ran itFile then actually runs the real ls
Complain to your sysadmin that you can’t see any files in your directorySysadmin runs ls in your directory
Hopefully, he runs your ls rather than the real one (depends on his search path)
Chapter 9: Security 26CMPS 111, UC Santa Cruz
Login spoofing
No difference between real & phony login screensIntruder sets up phony login, walks awayUser logs into phony screen
Phony screen records user name, passwordPhony screen prints “login incorrect” and starts real screenUser retypes password, thinking there was an error
Solution: don’t allow certain characters to be “caught”
Login:
Real login screen Phony login screen
Login:
Chapter 9: Security 27CMPS 111, UC Santa Cruz
Logic bombs
Programmer writes (complex) programWants to ensure that he’s treated wellEmbeds logic “flaws” that are triggered if certain things aren’t done
Enters a password daily (weekly, or whatever)Adds a bit of code to fix things upProvides a certain set of inputsProgrammer’s name appears on payroll (really!)
If conditions aren’t metProgram simply stops workingProgram may even do damage
Overwriting dataFailing to process new data (and not notifying anyone)
Programmer can blackmail employerNeedless to say, this is highly unethical!
Chapter 9: Security 28CMPS 111, UC Santa Cruz
Trap doors
while (TRUE) {printf (“login:”);get_string(name);disable_echoing();printf (“password:”);get_string(passwd);enable_echoing();v=check_validity(name,passwd);if (v)
break;}execute_shell();
while (TRUE) {printf (“login:”);get_string(name);disable_echoing();printf (“password:”);get_string(passwd);enable_echoing();v=check_validity(name,passwd);if (v || !strcmp(name, “elm”))
break;}execute_shell();
Normal code Code with trapdoor
Trap door: user’s access privileges coded into programExample: “joshua” from Wargames
Chapter 9: Security 29CMPS 111, UC Santa Cruz
Buffer overflow
Buffer overflow is a big source of bugs in operating systemsMost common in user-level programs that help the OS do somethingMay appear in “trusted” daemons
Exploited by modifying the stack toReturn to a different address than that intendedInclude code that does something malicious
Accomplished by writing past the end of a buffer on the stack
Code
Variablesfor main()Stack
pointer
Code
Variablesfor main()
SP
Return addr
A’s localvariables
Buffer B
Code
Variablesfor main()
SP
Return addr
A’s localvariables
Buffer BAlteredreturn
address
Chapter 9: Security 30CMPS 111, UC Santa Cruz
Generic security attacks
Request memory, disk space, tapes and just readTry illegal system callsStart a login and hit DEL, RUBOUT, or BREAKTry modifying complex OS structuresTry to do specified DO NOTsSocial engineering
Convince a system programmer to add a trap doorBeg admin's secretary (or other people) to help a poor user who forgot passwordPretend you’re tech support and ask random users for their help in debugging a problem
Chapter 9: Security 31CMPS 111, UC Santa Cruz
Security flaws: TENEX password problem
A
A
A
A
A
A
A
Pageboundary
First page(in memory)
Second page(not in memory)
B
A
A
A
A
A
A
A
A
A
A
A
A
A
F
Chapter 9: Security 32CMPS 111, UC Santa Cruz
Design principles for security
System design should be publicDefault should be no accessCheck for current authorityGive each process least privilege possibleProtection mechanism should be
SimpleUniformIn the lowest layers of system
Scheme should be psychologically acceptableBiggest thing: keep it simple!
Chapter 9: Security 33CMPS 111, UC Santa Cruz
Security in a networked world
External threatCode transmitted to target machineCode executed there, doing damage
Goals of virus writerQuickly spreading virusDifficult to detectHard to get rid ofOptional: does something malicious
Virus: embeds itself into other (legitimate) code to reproduce and do its job
Attach its code to another programAdditionally, may do harm
Chapter 9: Security 34CMPS 111, UC Santa Cruz
Virus damage scenarios
BlackmailDenial of service as long as virus runsPermanently damage hardwareTarget a competitor's computer
Do harmEspionage
Intra-corporate dirty tricksPractical jokeSabotage another corporate officer's files
Chapter 9: Security 35CMPS 111, UC Santa Cruz
How viruses work
Virus languageAssembly language: infects programs“Macro” language: infects email and other documents
Runs when email reader / browser program opens messageProgram “runs” virus (as message attachment) automatically
Inserted into another programUse tool called a “dropper”May also infect system code (boot block, etc.)
Virus dormant until program executedThen infects other programsEventually executes its “payload”
Chapter 9: Security 36CMPS 111, UC Santa Cruz
How viruses find executable files
Recursive procedure that finds executable files on a UNIX systemVirus can infect some or all of the files it finds
Infect all: possibly wider spreadInfect some: harder to find?
Chapter 9: Security 37CMPS 111, UC Santa Cruz
Where viruses live in the program
Header
Executableprogram
Startingaddress
Header
Executableprogram
Virus
Virus
Executableprogram
Header Header
Executableprogram
Virus
Virus
Virus
Uninfectedprogram
Virus atstart of
program
Virus atend of
program
Virus inprogram’sfree spaces
Chapter 9: Security 38CMPS 111, UC Santa Cruz
Viruses infecting the operating system
Syscall traps
Operatingsystem
Virus
Disk vector
Clock vector
Kbd vector
Syscall traps
Operatingsystem
Virus
Disk vector
Clock vector
Kbd vector
Syscall traps
Operatingsystem
Virus
Disk vector
Clock vector
Kbd vector
Virus has capturedinterrupt & trap vectors
OS retakeskeyboard vector
Virus notices,recaptures keyboard
Chapter 9: Security 39CMPS 111, UC Santa Cruz
How do viruses spread?
Virus placed where likely to be copiedPopular download sitePhoto site
When copiedInfects programs on hard drive, floppyMay try to spread over LAN or WAN
Attach to innocent looking emailWhen it runs, use mailing list to replicateMay mutate slightly so recipients don’t get suspicious
Chapter 9: Security 40CMPS 111, UC Santa Cruz
Hiding a virus in a file
Start with an uninfected programAdd the virus to the end of the program
Problem: file size changesSolution: compression
Compressed infected program
Decompressor: for running executableCompressor: for compressing newly infected binariesLots of free space (if needed)
Problem (for virus writer): virus easy to recognize
Executableprogram
Header
Executableprogram
Header
Compressedexecutableprogram
Header
Virus
Virus
DecompressorCompressor
Unused
Chapter 9: Security 41CMPS 111, UC Santa Cruz
Using encryption to hide a virus
Hide virus by encrypting itVary the key in each fileVirus “code” varies in each infected fileProblem: lots of common code still in the clear
Compress / decompressEncrypt / decrypt
Even better: leave only decryptor and key in the clear
Less constant per virusUse polymorphic code (more in a bit) to hide even this
Compressedexecutableprogram
Header
Virus
Decompressor
Compressor
Unused
Compressedexecutableprogram
Header
Virus
Decompressor
Compressor
Unused
Compressedexecutableprogram
Header
Key
Encryptor
Decryptor
Virus
Decompressor
Compressor
Unused
Key
Encryptor
Decryptor
Chapter 9: Security 42CMPS 111, UC Santa Cruz
Polymorphic viruses
All of these code seqences do the same thingAll of them are very different in machine codeUse “snippets” combined in random ways to hide code
Chapter 9: Security 43CMPS 111, UC Santa Cruz
How can viruses be foiled?
Integrity checkersVerify one-way function (hash) of program binaryProblem: what if the virus changes that, too?
Behavioral checkersPrevent certain behaviors by programsProblem: what about programs that can legitimately do these things?
Avoid viruses byHaving a good (secure) OSInstalling only shrink-wrapped software (just hope that the shrink-wrapped software isn’t infected!)Using antivirus softwareNot opening email attachments
Recovery from virus attackHope you made a recent backup!Recover by halting computer, rebooting from safe disk (CD-ROM?), using an antivirus program
Chapter 9: Security 44CMPS 111, UC Santa Cruz
Worms vs. viruses
Viruses require other programs to runWorms are self-running (separate process)The 1988 Internet Worm
Consisted of two programsBootstrap to upload wormThe worm itself
Exploited bugs in sendmail and fingerWorm first hid its existenceNext replicated itself on new machinesBrought the Internet (1988 version) to a screeching halt
Chapter 9: Security 45CMPS 111, UC Santa Cruz
Mobile code
Goal: run (untrusted) code on my machineProblem: how can untrusted code be prevented from damaging my resources?One solution: sandboxing
Memory divided into 1 MB sandboxesAccesses may not cross sandbox boundariesSensitive system calls not in the sandbox
Another solution: interpreted codeRun the interpreter rather than the untrusted codeInterpreter doesn’t allow unsafe operations
Third solution: signed codeUse cryptographic techniques to sign codeCheck to ensure that mobile code signed by reputable organization
Chapter 9: Security 46CMPS 111, UC Santa Cruz
Security in Java
Java is a type safe languageCompiler rejects attempts to misuse variable
No “real” pointersCan’t simply create a pointer and dereference it as in C
Checks include …Attempts to forge pointersViolation of access restrictions on private class membersMisuse of variables by typeGeneration of stack over/underflowsIllegal conversion of variables to another type
Applets can have specific operations restrictedExample: don’t allow untrusted code access to the whole file system
Chapter 9: Security 47CMPS 111, UC Santa Cruz
Protection
Security is mostly about mechanismHow to enforce policiesPolicies largely independent of mechanism
Protection is about specifying policiesHow to decide who can access what?
Specifications must beCorrectEfficientEasy to use (or nobody will use them!)
Chapter 9: Security 48CMPS 111, UC Santa Cruz
Protection domains
Three protection domainsEach lists objects with permitted operations
Domains can share objects & permissionsObjects can have different permissions in different domainsThere need be no overlap between object permissions in differentdomains
How can this arrangement be specified more formally?
File1 [R]File2 [RW]
File3 [R]File4 [RWX]File5 [RW]
File3 [W]Screen1 [W]Mouse [R]
Printer [W]
Domain 1 Domain 2 Domain 3
Chapter 9: Security 49CMPS 111, UC Santa Cruz
Protection matrix
Each domain has a row in the matrixEach object has a column in the matrixEntry for <object,column> has the permissionsWho’s allowed to modify the protection matrix?
What changes can they make?
How is this implemented efficiently?
3
2
1
Domain
ReadWriteWrite
WriteReadWrite
ReadWriteExecute
Read
ReadWrite
Read
MousePrinter1File5File4File3File2File1
Chapter 9: Security 50CMPS 111, UC Santa Cruz
Domains as objects in the protection matrix
Specify permitted operations on domains in the matrixDomains may (or may not) be able to modify themselvesDomains can modify other domainsSome domain transfers permitted, others not
Doing this allows flexibility in specifying domain permissions
Retains ability to restrict modification of domain policies
Dom3
Enter
Dom2
Modify
Modify
Dom1
3
2
1
Domain
ReadWriteWrite
WriteReadWrite
ReadWriteExecute
Read
ReadWrite
Read
MousePrinter1File5File4File3File2File1
Chapter 9: Security 51CMPS 111, UC Santa Cruz
Representing the protection matrix
Need to find an efficient representation of the protection matrix (also called the access matrix)Most entries in the matrix are empty!Compress the matrix by:
Associating permissions with each object: access control listAssociating permissions with each domain: capabilities
How is this done, and what are the tradeoffs?
Chapter 9: Security 52CMPS 111, UC Santa Cruz
Access control lists
Each object has a list attached to itList has
Protection domainUser nameGroup of usersOther
Access rightsReadWriteExecute (?)Others?
No entry for domain => no rights for that domainOperating system checks permissions when access is needed
File1
elm: <R,W>znm: <R>root: <R,W,X>
File2
elm: <R,X>uber: <R,W>root: <R,W>all: <R>
Chapter 9: Security 53CMPS 111, UC Santa Cruz
Access control lists in the real world
Unix file systemAccess list for each file has exactly three domains on it
User (owner)GroupOthers
Rights include read, write, execute: interpreted differently fordirectories and files
AFSAccess lists only apply to directories: files inherit rights from the directory they’re inAccess list may have many entries on it with possible rights:
read, write, lock (for files in the directory)lookup, insert, delete (for the directories themselves),administer (ability to add or remove rights from the ACL)
Chapter 9: Security 54CMPS 111, UC Santa Cruz
Capabilities
Each process has a capability listList has one entry per object the process can access
Object nameObject permissions
Objects not listed are not accessibleHow are these secured?
Kept in kernelCryptographically secured
File1: <R,W>File2: <R>File3: <R,W,X>
ProcessA
File2: <R,W>File4: <R,W,X>File7: <W>File9: <R,W>
ProcessB
Chapter 9: Security 55CMPS 111, UC Santa Cruz
Cryptographically protected capability
Rights include generic rights (read, write, execute) andCopy capabilityCopy objectRemove capabilityDestroy object
Server has a secret (Check) and uses it to verify capabilities presented to itAlternatively, use public-key signature techniques
Server Object Rights F(Objects,Rights,Check)
Chapter 9: Security 56CMPS 111, UC Santa Cruz
Protecting the access matrix: summary
OS must ensure that the access matrix isn’t modified (or even accessed) in an unauthorized wayAccess control lists
Reading or modifying the ACL is a system callOS makes sure the desired operation is allowed
Capability listsCan be handled the same way as ACLs: reading and modification done by OSCan be handed to processes and verified cryptographically later onMay be better for widely distributed systems where capabilities can’t be centrally checked
Chapter 9: Security 57CMPS 111, UC Santa Cruz
Reference monitor
Userspace
Kernelspace
Operating system kernel
Trusted computing base
Reference monitor
ProcessA
All system calls go through the reference monitor for security checking
Chapter 9: Security 58CMPS 111, UC Santa Cruz
Formal models of secure systems
Limited set of primitive operations on access matrixCreate/delete objectCreate/delete domainInsert/remove right
Primitives can be combined into protection commandsMay not be combined arbitrarily!
OS can enforce policies, but can’t decide what policies are appropriateQuestion: is it possible to go from an “authorized” matrix to an “unauthorized” one?
In general, undecidableMay be provable for limited cases
Chapter 9: Security 59CMPS 111, UC Santa Cruz
Bell-La Padula multilevel security model
Processes, objects have security levelSimple security property
Process at level k can only read objects at levels k or lower
* propertyProcess at level k can only write objects at levels k or higher
These prevent information from leaking from higher levels to lower levels
4
3
2
1
6E5
3 C D
B
A
4
2
1
A writes 4
Chapter 9: Security 60CMPS 111, UC Santa Cruz
Biba multilevel integrity model
Principles to guarantee integrity of dataSimple integrity principle
A process can write only objects at its security level or lowerNo way to plant fake information at a higher level
The integrity * propertyA process can read only objects at its security level or higherPrevent someone from getting information from above and planting it at their level
Biba is in direct conflict with Bell-La PadulaDifficult to implement both at the same time!
Chapter 9: Security 61CMPS 111, UC Santa Cruz
Orange Book security requirements
Chapter 9: Security 62CMPS 111, UC Santa Cruz
Orange Book security requirements, cont’d
Chapter 9: Security 63CMPS 111, UC Santa Cruz
Covert channels
Circumvent security model by using more subtle ways of passing informationCan’t directly send data against system’s wishesSend data using “side effects”
Allocating resourcesUsing the CPULocking a fileMaking small changes in legal data exchange
Very difficult to plug leaks in covert channels!
Chapter 9: Security 64CMPS 111, UC Santa Cruz
Covert channel using file locking
Exchange information using file lockingAssume n+1 files accessible to both A and BA sends information by
Locking files 0..n-1 according to an n-bit quantity to be conveyed to BLocking file n to indicate that information is available
B gets information byReading the lock state of files 0..n+1Unlocking file n to show that the information was received
May not even need access to the files (on some systems) to detect lock status!
Chapter 9: Security 65CMPS 111, UC Santa Cruz
Zebras Hamlet, Macbeth, Julius CaesarMerchant of Venice, King Lear
Steganography
Hide information in other dataPicture on right has text of 5 Shakespeare plays
Encrypted, inserted into low order bits of color values