200 likes | 381 Views
SECURE CAPABILITY SYSTEMS. CONTENTS. Introduction Fundamentals Capability Security Challenges in Secure Capability Systems Revoking Capabilities Conclusion. INTRODUCTION.
E N D
CONTENTS • Introduction • Fundamentals • Capability Security • Challenges in Secure Capability Systems • Revoking Capabilities • Conclusion
INTRODUCTION • A capability system is an operating system that represents its access control policy from the subject’s perspective. • “capabilities” were first introduced by Dennis and Van Horn in 1966, as a reference to an object and a set of operations that the capability entitles the holder.
FUNDAMENTALS • Such capability references are extended memory references in that they not only provide location or naming information, but they may also provide access rights for that reference. This form of addressing is known as capability-based addressing. • An important difference between capability and access control list systems is the process’s ability to name objects, where in an access control list system, a process can name any object in the system as the target of an operation.
FUNDAMENTALS • A fundamental requirement of a capability system is that processes not be able to modify or forge capabilities. • If the capabilities could be forged, then a process could build a capability for any access it desires. • To protect capabilities, the capability systems traditionally store them in memory protected from the process.
CAPABILITY SECURITY • Capability systems have conceptual security advantages over ordinary systems: • They can be used to define process permissions more precisely, enabling least privilege. • They enable permissions to be more easily transferred from one process to another, enabling the definition of protected subsystems.
CAPABILITY SECURITY • A computer program that is fooled by some other party intomisusing its authority, is defined as confused deputy. • In an ordinary operating system, objects are assigned permissions and it is inconvenient to change which subjects can access an object at runtime. • Then, the subsystem would be assigned the rights to operate on behalf of any client. If a subsystem is confused, there is a chance of providing unauthorized access to another client’s data.
CAPABILITY SECURITY • But in the case of a capability system, this would not be possible because the subsystem would only be able to perform operations using the capabilities that the client would provide.
CHALLENGES IN SECURECAPABILITY SYSTEMS • Here we will discuss whether a capability system architecture is suitable for implementing a secure operating system. • Mr.Boebert and Mr.Karger noted that traditional capability systems fail to implement the –security property of the Bell-LaPadulapolicy.
CHALLENGES IN SECURECAPABILITY SYSTEMS • In the above figure there are two processes: High Secrecy Process A has access to high secrecy data and Low Secrecy Process B is not authorized to access that data. • If our goal is to implement an MLS (multilevel security) policy like Bell-LaPadula, then a high secrecy process may read data in a low secrecy process. • For instance, A uses its legal capability B1 to read segment B1 and since capabilities are data, the high secrecy process A can read the capabilities, and then A1 can write in the low secrecy process’s segment B1.
CHALLENGES IN SECURECAPABILITY SYSTEMS • Then high secrecy process A has a capability to write its secrets to low secrecy segment B2 which violates -security property.
REVOKING CAPABILITIES • Here in Revocation in capability systems, the owner of an object has a choice whether to grant normal capabilities or grant capabilities that are associated with a special revoker capability. • Revoker capability is a level of indirection that enables the owner to revoke all the capabilities that reference the object though that revoker capability. • And simply by deleting the revoker capability, the other capabilities lose access to the object and this is because the object is only available via the revoker capability.
REVOKING CAPABILITIES • This approach is explained by “Redell’s revoker capability approach” which states “When the revoker capability is revoked all the capabilities that were based on it are also revoked.
REVOKING CAPABILITIES • An owner creates a revoker capability and grants a capability that points to that revoker capability to Process1. • Revoker capabilities may be used by other subjects as well. Process1can also create revoker capability and create a capability that points to it for Process2. • Thus the owner will revoke both Process 1 and Process 2 access should they delete their revoker capability.
REVOKING CAPABILITIES • However the Process 1can only revoke access from Process 2 and note that the capability for Process 3 cannot be revoked because it points directly to the object.
CONCLUSION • The biggest challenge for this capability systems, like many systems, is providing a practical execution environment that can be proven to ensure systems security goals.
BIBLIOGRAPHY • http://www.eros-os.org/essays/capintro.html • http://en.wikipedia.org/wiki/Capability-based_security • Reference from Textbook.