PSU CSE 543 - THE PROTECTION OF INFORMATION IN COMPUTER SYSTEMS

Unformatted text preview:

THE PROTECTION OF INFORMATION IN COMPUTER SYSTEMS – II.2Presented by Sharanya EswaranOUTLINE• Access control matrix, ACL, capabilities• Implementation and issues of capabilities• Implementation and issues of access controllers• Protected subsystem• Implementation and issues of protected subsystemsPROTECTION STATE OF A SYSTEM• Lampson’s Access control matrix model• Sparse matrix – how to store? • Along column – Access Control List– op in acl(obj, principal(p))– Tamper-proof• Along row – Capabilities– :: Tickets / keys– op in ops(caps(p, i))– Unforgeable• Equivalent? – Capabilities have no reference to the notion of ‘principal’INTUITIVELY…• Each has its advantages and disadvantages• When do ACLs make more sense?– Given an object, what subjects can access it and how?– ‘Owned’ objects. E.g. file management• When do capabilities make more sense?– Given a subject, what objects can it access and how?– ‘Functionalities / capabilities of a process’ –object space of a process – memory managementAPPLICATIONS OF CAPABILITIES AND ACLs• Capabilities– Page table entry– File descriptors– Passwords– Java object reference (can’t forge because of Java’s type-safety)•ACL– Unix file or process permissions• Pure capability-based systems– E.g. EROS (JHU, UPenn), CAP (Cambridge)• Pure ACL-based system?• Typically hybridSYSTEM ARCHITECTURE• Segmented memory• Objects – memory segments•Descriptors – For mapping segments to physical address– Can be used as a capability for protection R W Unique segment id base limit• Correlate with segment registers and segment tablePROTECTING A CAPABILITY• Has to be unforgeable•Three mechanisms(i) Tagged architecture (ii) Protected memory(iii) CryptographyTAGGED ARCHITECTURE• Capability can be stored anywhere in memory• Every word in a memory has an extra bit –capability or data• Flexibility – process can store its capabilities wherever it wants• Disadv: hardware support, search time• E.g. IBM AS/400(Assumed in this paper, as it’s the general case)PROTECTED MEMORY• Place capabilities in memory space readable by user processes, but not changeable• Efficient if all capabilities for a process are placed together in one (or more) segments– C-lists• No extra hardware required• E.g. Unix region tableCRYPTOGRAPHY• Capabilities are encrypted to prevent forgery• Computational overhead• Developed for distributed OS - AmoebaWORKING OF THE SYSTEM1) Supervisor wants to schedule the process A2) It possesses capability for progA (code segment)3) It has capability for catalog of user of A (capability segment –segment table)– loads them in protection description regs4) Starts running process A- does not clear the registers4) A uses catalog to retrieve further capabilitiesCOMPLETE PICTURE…• Need to authenticate the user running the process.Capability for UID table1) Supervisor’s authentication process runs with the capability for UID table2) User logs in, providing his password3) If authenticated, supervisor does the following:(ii) Loads the capability for the user’s catalog (iii) Loads the capability of a progbelonging to the user (typically the entry code segment)(iv) Starts running processCapability for catalogCapability for code seg(i) clears the prot desc regSupervisor’s address spaceUser’s address spaceDYNAMIC SHARING• We need a special communication segment between pairs of users – to pass the capability• If there are N users, O(N2) extra segments• Can use a ‘mailbox’ segment for each receiver, where each sender places the capability – O(N)– Mailbox must be able to associate sender’s id with the capability– Must be able to associate the receiver’s id with it lfISSUES…• Users can copy capabilities dynamically without any constraint.– There’s no control of propagation⇒Difficult to review which users have access to a segment⇒Revocation of capabilities is a problem(especially in a tagged architecture)QUICKFIXES•Copy bit•Depth counter• Indirect object access• A better alternative?ACCESS CONTROL SYSTEMCAN GET MESSY…• Every segment has an access controller• Every access requires a lot of memory reads• Access controllers may change size dynamically• No issues with uncontrolled propagation, revocation or reviewQUICKFIXES• When authorized for first time, provide a capability for that principal with the access rights to that object, which can be used for subsequent accesses• Group the users – restrict number of entries– E.g. Unix restricts to three – owner, group and others• Better alternative?– Hybrid system– Capabilities for memory (high-traffic path)– Access controllers for secondary storage and file system– E.g. process (uid) Æ fopen (file name) Æ ACL check ÆfdWHO GIVES AUTHORITY FOR ACCESS ?• Discretionary– Self-control– Hierarchical•Mandatory–More secure– Bell-La Padula, high water mark models– But covert channels…PROTECTING OBJECTS OTHER THAN SEGMENTS• User-defined objects• Protected subsystem– Collection of objects and processes with exclusive capabilities on the objects– E.g., Unix kernel, Java sandboxIMPLEMENTING A PROTECTED SUBSYSTEM• Involves computation across several protection domains⇒Switching of protection domains⇒Replacing C-lists of one domain with another• Implemented as procedure calls- The entry-procedure of one domain requires the calling domain to have ‘Enter’ capability- E.g. Unix system callsIMPLEMENTATION ISSUES• To name just a few…(i) Separation of privilege required for security- To access internal structure of an object, two capabilities are needed; both must allow access - E.g. setuid in Unix, forking in sshd(ii) Book-keeping data of the domains must be preserved (activation records and static variables)(iii) Argument passing- In Unix, when returning from kernel mode, it is checked if the calling user has valid rights for the return address- Buffer overflow attackCONCLUSION• A comprehensive overview of information protection• Gives the trend at that time, and the various research directions• No drastic change since then, we still have the same issues, we still have a lot of similarities with existing


View Full Document

PSU CSE 543 - THE PROTECTION OF INFORMATION IN COMPUTER SYSTEMS

Documents in this Course
Agenda

Agenda

14 pages

HYDRA

HYDRA

11 pages

PRIMA

PRIMA

15 pages

CLIMATE

CLIMATE

15 pages

Load more
Download THE PROTECTION OF INFORMATION IN COMPUTER SYSTEMS
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view THE PROTECTION OF INFORMATION IN COMPUTER SYSTEMS and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view THE PROTECTION OF INFORMATION IN COMPUTER SYSTEMS 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?