CS363

1. Week 8 - Friday CS363

2. Last time • What did we talk about last time? • Bell-La Padula model • Clark-Wilson model • Chinese Wall model • Biba model

3. Questions?

4. Project 2

5. Assignment 3

6. Security Presentation Taylor Ryan

7. Theoretical Limitations on Access Control

8. Determining security • How do we know if something is secure? • We define our security policy using our access control matrix • We say that a right is leaked if it is added to an element of the access control matrix that doesn’t already have it • A system is secure if there is no way rights can be leaked • Is there an algorithm to determine if a system is secure?

9. Mono-operational systems • In a mono-operational system, each command consists of a single primitive command: • Create subject s • Create object o • Enter r into a[s,o] • Delete r from a[s,o] • Destroy subject s • Destroy object o • In this system, we could see if a right is leaked with a sequence of k commands

10. Proof • Delete and Destroy commands can be ignored • No more than one Create command is needed (in the case that there are no subjects) • Entering rights is the trouble • We start with set S0 of subjects and O0 of objects • With n generic rights, we might add all n rights to everything before we leak a right • Thus, the maximum length of the command sequence that leaks a right is k ≤ n(|S0|+1)(|O0|+1) + 1 • If there are m different commands, how many different command sequences are possible?

11. Turing machine • A Turing machine is a mathematical model for computation • It consists of a head, an infinitely long tape, a set of possible states, and an alphabet of characters that can be written on the tape • A list of rules saying what it should write and should it move left or right given the current symbol and state A

12. Turing machine example • 3 state, 2 symbol “busy beaver” Turing machine: • Starting state A

13. Church-Turing thesis • If an algorithm exists, a Turing machine can perform that algorithm • In essence, a Turing machine is the most powerful model we have of computation • Power, in this sense, means the ability to compute some function, not the speed associated with its computation

14. Halting problem • Given a Turing machine and input x, does it reach the halt state? • It turns out that this problem is undecidable • That means that there is no algorithm that can be to determine if any Turing machine will go into an infinite loop • Consequently, there is no algorithm that can take any program and check to see if it goes into an infinite loop

15. Leaking Undecidable

16. Simulate a Turing machine • We can simulate a Turing machine using an access control matrix • We map the symbols, states and tape for the Turing machine onto the rights and cells of an access control matrix • Discovering whether or not the right leaks is equivalent to the Turing machine halting with a 1 or a 0

17. The bad news • Without heavy restrictions on the rules for an access control, it is impossible to construct an algorithm that will determine if a right leaks • Even for a mono-operational system, the problem might take an infeasible amount of time • But, we don’t give up! • There are still lots of ways to model security • Some of them offer more practical results

18. Secure Design Principles

19. Secure design principles • Saltzer and Schroeder wrote an important paper in 1975 that gave 8 principles that should be used in the design of any security mechanisms • Least privilege • Fail-safe defaults • Economy of mechanism • Complete mediation • Open design • Separation of privilege • Least common mechanism • Psychological acceptability • These principles will be part of Project 3

20. Principle of least privilege • The principle of least privilege states that a subject should be given only those privileges that it needs in order to complete its task • This principle restricts how privileges are granted • You're not supposed to get any more privileges than absolutely necessary • Examples • JayWeb • Unix systems • Windows systems?

21. Principle of fail-safe defaults • The principle of fail-safe defaults states that, unless a subject is given explicit access to an object, it should be denied access to an object • This principle restricts how privileges are initialized • A subject should always be assumed not to have access • Examples • Airports • Unix systems • Windows systems?

22. Principle of economy of mechanism • The principle of economy of mechanism states that security mechanisms should be as simple as possible • This principle simplifies the design and implementation of security mechanisms • The more complex a system is, the more assumptions that are built in • Complex systems are hard to test • Examples • Die Hard • Houdini

23. Principle of complete mediation • The principle of complete mediation requires that all access to objects be checked to ensure that they are allowed • This principle restricts the caching of information (and also direct access to resources) • The OS must mediate all accesses and make no assumptions that privileges haven't changed • Examples • Banks • Unix systems

24. Principle of open design • The principle of open design states that the security of a mechanism should not depend on the secrecy of its design or implementation • "Security through obscurity" fallacy • Examples • Enigma • RSA • Lock-picking

25. Principle of separation of privilege • The principle of separation of privilege states that a system should not grant permission based on a single condition • Security should be based on several different conditions (perhaps two-factor authentication) • Ideally, secure mechanisms should depend on two or more independent verifiers • Examples • Nuclear launch keys • PhD qualifying exams • Roaccutane (used to be Accutane)

26. Principle of least common mechanism • The principle of least common mechanism states that mechanisms used to access resources should not be shared • Sharing allows for channels for communication • Sharing also lets malicious users or programs affect the integrity of other programs or data • Examples • Virtual memory • File systems

27. Principle of psychological acceptability • The principle of psychological acceptability states that security mechanisms should not make the resource (much) more difficult to access than if the security mechanisms were not present • Two fold issues: • Users must not be inconvenienced or they might fight against the system or take their business elsewhere • Administrators must find the system easy to administer • Examples • Windows UAC • Retina scans • Changing your password all the time

28. OS Security Features

29. Regular OS • A typical OS will make efforts to protect security in a number of ways: • User authentication • Memory protection • File and I/O device access control • Allocation and access to general objects • Enforced sharing • Guaranteed fair service • Interprocess communication and synchronization • Protection of OS data

30. Trusted OS • A trusted OS is similar to a normal OS, except that it puts a layer of access control around everything • A trusted OS will typically be careful about: • User identification and authentication • Mandatory access control • Discretionary access control • Object reuse protection • Complete mediation • Trusted paths • Auditing • Intrusion detection

31. Mandatory and discretionary access control • Mandatory access control (MAC) means that the controls are enforced by rules in the system, not by user choices • Bell-La Padula is a perfect example of MAC • Discretionary access control (DAC) means that the user has control over who can access the objects he or she owns • Linux and Windows are largely DAC systems • Most real systems have elements of both

32. Object reuse • When a file is deleted, it isn’t actually deleted • It’s blocks are unlinked from the file system • When you create a new file, it usually uses a block from an old deleted file • You can examine the contents of that block and reconstruct some or all of the deleted file • Software is available for home users to undelete files • Digital forensics experts use more powerful tools in criminal investigations • The problem is that object reuse allows for security violations • A regular OS often does this and other kinds of object reuse for efficiency • A trusted OS will sacrifice efficiency for security

33. Complete mediation and trusted paths • Complete mediation means that every access goes through the system • All resources are checked • Past permissions are no guarantee of future permissions • A trusted path means an unmistakable process for performing protected tasks • Phishing is the opposite of a trusted path • Some attacks on OS users rely on getting them to download a file with the same name as a system command, which will then be run instead if they execute from the same directory

34. Auditing • Trusted systems also keep an audit log of all security-relevant actions that have been taken • Unfortunately, audit logs can become huge • Even if an illegal access is known to have happened, it might be impossible to find it in the logs • Audit reduction is the process of reducing the size of the log to critical events • This may require sophisticated pattern recognition software

35. Kernelized design • One approach to making a trusted system is a kernelized design • A security kernel is the low level part of the OS that enforces security mechanisms • It can be a unified layer sitting between hardware and the rest of the OS • Or it can be spread throughout the entire OS • The reference monitor is the most important part of the security kernel • It controls accesses to objects • It should be tamperproof, unbypassable, and analyzable

36. Virtualization • Virtualization means presenting the user with a virtual machine • The user can interact with the virtual machine but cannot directly affect the real hardware • Virtual memory is a great example of this • Your program sees memory starting at 0 and going up to some limit, but the OS maps this transparently to the real memory

37. OS Assurance

38. Common OS Security Flaws • User interaction is problematic because input is often not under the direct control of the OS • Hardware can vary, and it is hard to check all software drivers • Sometimes security measure are bypassed for efficiency • Ambiguity in access policy • Incomplete mediation • Generality • Customizability leads to unpredictable configurations or special modules that need high privilege access • Time-of-check to time-of-use issues

39. Assurance • There are many methods to provide assurance that a system has few vulnerabilities: • Testing • Penetration testing • Formal verification • Validation • Open source model

40. Testing • We discussed testing briefly before • It has problems: • Testing can find problems, but it can’t find the lack of problems • Testing takes time and effort because the number of states a program can undergo is exponential in its length • Black box testing cannot be guaranteed to be complete • Code introduced into a program to test it can change its behavior • Complex systems can have errors that are difficult to reproduce • It is still the most common form of assurance

41. Penetration Testing • Penetration testing (or tiger team analysis or ethical hacking) is a kind of testing where experts try to use every trick they can to break a system • It is an art requiring creativity and a science requiring deep technical knowledge • It is not a panacea, but there is money to be made as a penetration tester

42. Formal verification • It is possible to prove that some programs do specific things • You start with a set of preconditions • You transform those conditions with each operation • You can then guarantee that, with the initial preconditions, certain postconditions will be met • Using this precondition/postcondition approach to formally describe programming languages is called Hoare semantics • Proving things about complex programs is hard and requires automated use of programs called theorem provers

43. Validation • Validation is checking the design against the requirements • Verification is checking the implementation against the design • OS validation is often done in the following ways: • Requirements checking • Design and code reviews • System testing

44. Open source systems • In open source systems, the software is freely available for public use and criticism • In most cases, anyone sufficiently skilled can even add their own code to the systems • They are popular • Microsoft CEO Steve Ballmer said in 2008 that 60% of the web servers in the world run Linux • The open source security advantage is that a huge number of people can look for flaws • The open source security disadvantage is the same • Research suggests that a product being open source or closed source is not the key determiner of security

45. Upcoming

46. Next time… • Finish OS assurance and evaluation • Database background • Database security requirements • Claire Chamblesspresents

47. Reminders • Read Sections 6.1 and 6.2 • Finish Assignment 3 • Due tonight before midnight • Keep working on Project 2 • Due next Friday