Presentation is loading. Please wait.

Presentation is loading. Please wait.

Secure Operating Systems Lesson 9: Multics. Where are we?  We now know all the background… so it’s time to figure out why Dr. Ford likes Multics so very.

Similar presentations


Presentation on theme: "Secure Operating Systems Lesson 9: Multics. Where are we?  We now know all the background… so it’s time to figure out why Dr. Ford likes Multics so very."— Presentation transcript:

1 Secure Operating Systems Lesson 9: Multics

2 Where are we?  We now know all the background… so it’s time to figure out why Dr. Ford likes Multics so very much Multics is pretty much the poster child for “proper” system design And we did it years ago

3 A Little History: 1963  Cuba transactions made illegal  Debut of Iron Man!!!  Beatles release their first album…  First James Bond movie  UCF founded  ZIP codes introduced  IEEE founded, ASCII introduced  Kevin Mitnick born ;)

4 In the Midst…  The Multics project begins  The move from batch systems to timesharing  Released as a commercial project in 1973… that’s a 10 year development cycle

5 Processes  We’re very comfortable with this idea, but it was newer then  Processes are the things that execute stuff in Multics  All the things the process accesses are stored as “segments”  The “protection domain” determines the segments a process can access

6 Segments  These are created hierarchically  This became the roadmap to things like the Unix file system  The process has a descriptor segment which contains a set of segment descriptor words (SDWs) that refer to all the segments the process can access directly

7 Security  Three primary parts: the supervisor, protection rings, and SDWs  The supervisor is the ultimate arbiter – it decides if a process can have a SDW This is isolated from other processes by protection rings (64 possible) The basic idea was to protect the supervisor from unauthorized changes

8 Segment Access Control  Simple ACL Segments: read, write, execute Directories: status, modify, append  However. The SDW also includes rings and brackets – this can be a little tricky  To grant access, the ACL and Access brackets must both allow…

9 Rings/Brackets  Imagine we have code running in Ring r.  Access brackets define access – range of rings is r 1, r 2 where r 1 < r 2  If r < r 1, the process has full access (r/w)  If r 1 ≤ r ≤ r 2, the process can read the segment only  If r 2 < r, then the process has no access

10 Call Brackets  Imagine we have code running in Ring r, trying to invoke a code segment  Call brackets define access – range of rings is (r 2, r 3 ) where r 2 ≤ r 3  If r < r 1, the process can execute, but there is a loss of privilege, where r changes to r_prime  If r 1 ≤ r ≤ r 2, the process executes with its current privilege  If r 2 ≤ r ≤ r 3, the process executes with higher privilege IF the location is authorized by the gates  If r 3 < r, then the process has no access

11 MLS  Multilevel Security was pioneered by Multics – the policy prevents a subject from reading data that is “more secret” than itself, or writing to objects that are “less secret”  This is part and parcel of the way the Multics protection system worked MLS is MAC, ACL and Ring Brackets are DAC  Think about performance for a minute…

12 The Gatekeeper  Multics tries hard to prevent the confused deputy problem…  The gatekeeper carefully (!) checks the parameters passed when privilege increases  The gatekeeper sometimes copies code to avoid giving a whole segment of the caller to the callee  The kernel is split between Ring 0 and 1 – the gatekeeper is Ring 0

13 Security Eval  Need: complete mediation, tamper proofing, and verifiability  How does Multics do?

14 Discussion  How does the reference monitor interface ensure that all security-sensitive operations are mediated correctly?  Does the reference monitor interface mediate security-sensitive operations on all system resources?  How do we verify that the reference monitor interface provides complete mediation?

15 Discussion  How does the system protect the reference monitor from modification?  Does the protection system protect all of the TCB?  What is the basis for the correctness of the system’s TCB?  Does the protection system enforce the system’s goals?

16 Multics Vulnerabilities  Karger and Schell’s analysis is very interesting  Primarily looks at implementation errors in the system  Actually included a hardware error that allowed instructions to bypass the SDW

17 Master Mode  To me, this is a classic  For performance, it’s ugly to have all traps dealt with by Ring 0  However, to handle that, we need a user level trap handler… which requires access to some privileged instructions  And the trap handler used a register to determine where to go… and thus, disaster

18 Lots to do!  2 weeks, large project  Write an essay that compares Multics with the modern OS of your choice: Linux, Windows or iOS. Look at the trajectory of your chosen OS, not just how it is today, but how it was  How does the modern OS handle the things that Multics already had?  You’re aiming at pages

19 Resources  You should read “Protection and the Control of Information Sharing in Multics” and “Thirty Years Later: Lessons from the Multics Security Evaluation”  Resource (long): Final Report of the Multics Kernel Design Project  We will discuss these papers a week Thursday, be ready to share your ideas

20 Questions & Comments  What do you want to know?


Download ppt "Secure Operating Systems Lesson 9: Multics. Where are we?  We now know all the background… so it’s time to figure out why Dr. Ford likes Multics so very."

Similar presentations


Ads by Google