Download Password-Capability System

Password Capabilities:
Their Evolution from the
Password-Capability System
into Walnut and Beyond
Dr. Ronald Pose
School of Computer Science & Software Engineering
Monash University
Melbourne, Australia.
[email protected]
Overview
•
•
•
•
•
•
•
•
•
•
The concept of capabilities
Kinds of capability systems
Password-Capabilities
Motivation for Password-Capability System
Overview of the Password-Capability System
Motivation for Walnut
Overview of Walnut
Motivation for Walnut’s successor
Possible approaches for the new system
Conclusions
Capability (concept)
• Methods needed to name, address and control
access to information in computer systems
• Naming / addressing usually based on whether
the information is permanent or temporary
– Permanent information is usually treated as files
• File names are character strings held in directories
– Temporary information is often treated as variables
• Variables have names and memory addresses
• Two main approaches used for access control:
– Access control lists
– Capabilities
Access Control Lists
• For each object in the system keep a list of
which subjects are allowed access and what
type of access
• Subjects may be encoded in a shorter form,
e.g. Unix owner/group/other categories
• Access rights may also be grouped for
convenience
• Critical features
– Identification of subjects
– Authentication of subjects
– Access control lists must be securely managed
Capabilities
• For each subject maintain a list of which
objects are accessible and their access rights
• Such a list defines the domain of the subject
• Each entry is a Capability confering the right to
use an object in some way
• Critical features
– Identification of objects
– Authentication and identification of subjects implicit
– Capabilities must be securely managed
Comparison
• Access Control Lists provide a way of
determining which active entities are permitted
to use resources
– Can be applied dynamically allowing fine grained
control of who and when they get or are denied
access to objects
• Capability list provides a way of determining
what resources are accessible to a subject
– Analogous to proving a key to the resource
– Can be difficult to retrieve key to revoke access
– May entail ‘changing the lock’
– Can be difficult to identify the user of the resource
Software Engineering for
Secure Systems
• ‘Object’ models have become popular in that
security and semantic integrity is enhanced by
implementing abstract data types and having
the security and integrity of type instances
guaranteed by having access only through
approved type managers
• Capabilities are a convenient method of
controlling access to type instances (objects)
by type managers (subjects)
– i.e. subjects need not be users or processes but
could be more abstract
Capability Implementation
• Tagging
– Tag memory to indicate whether it contains normal
data or a Capability which must be protected by the
system to prevent alteration of access rights etc.
• Segregation
– Segregate capabilities into separate areas which
are securely controlled by the system
• Password-Capabilities
– Allow free intermixing of normal data and
capabilities without expensive tagging hardware or
the inconvenience and overheads of segregation
Password-Capabilities
• A Password-Capability is a value, the
knowledge of which confers rights to gain some
kind of access to an object
– Does not necessarily require a system defined
presence or representation
– Does not need to be identified as a capability
– Security is probabilistic. It is extremely unlikely to
accidentally or deliberately discover a PasswordCapability
– Does not encode the access rights so needs no
intrinsic protection from alteration or forgery
Password-Capability
• A Password-Capability comprises 4 fields
– Volume number
– Serial number of object on volume
– 2 random password fields
• The volume/serial number form a globally
unique name (identifier) for the object
• The password fields are genuinely random and
identify a set of access rights permitted to the
object by the ‘possessor’ of the PasswordCapability
Password-Capability based
Persistent Virtual Memory
• Object name is analogous to a file name in a
distributed network file system
– Does not encode physical location
• Password fields confer access rights
– Access rights not encoded in Password-Capability
– Randomness and sparseness of passwords form
basis for probabilistic security
• In effect Password-Capabilities name and
control access to a global persistent virtual
memory in an extremely large and sparsely
populated virtual address space
Roles of Operating Systems
using Password-Capabilities
• The Operating System
– defines the semantics of the virtual memory
– is responsible for physically locating objects.
This is not encoded in the Password-Capability
and need not concern the user
– is thus free to distribute / relocate / replicate /
cache objects as it sees fit as long as the
semantics of the virtual memory are maintained
Motivation for the
Password-Capability System
• We wanted the advantages of a tagged
capability system (free intermixing of
capabilities and data in arbitrary data
structures) without the overheads of tagging
• We wanted the advantages of segregation
(no need to worry about the security and
integrity of capabilities since they are safely
stored away in a secure area) without the
inconvenience
• We wanted to support abstract data types
Password-Capability System
• Objects of two distinct kinds
– Processes
– Other Objects
• Processes
– Provides an execution environment and can
make calls on the operating system to manipulate
objects in the virtual memory including itself
• Other objects
– Are passive
– Only changed through actions of processes or
the operating system
Password-Capability System
Processes
• Processes can send/receive messages via
the operating system given capabilities
conferring such rights, but in general an inprocess style of operation is encouraged
• Processes define a logical address space in
which objects of current interest are mapped
although any object for which a capability is
known can also be manipulated via operating
system calls
• The logical address space is an efficiency
measure allowing processors direct access
Password-Capability System
Virtual Memory Operation
• Before an object can be manipulated
– A capability must be provided which confers the
required access rights over the object
– The system uses the volume number field of the
capability to find the volume on which the object
is located
– On that volume is a catalogue of all its objects
• For each object a hierarchy of Password-Capabilities
is maintained, each conferring certain access rights
• Each Password-Capability for the same object differs
only in its password fields
Password-Capability System
Locking and Sealing
• A process contains a ‘Lockword’, a value
which the system XORs with the password
fields of the presented capability before
checking the catalogue
– If the system finds an exact match then the
operations permitted by that capability can be
invoked
– However if the system only finds the first
password field matches, a very restricted subset
of operations is permitted
• Nothing which allow disclosure or alteration of the
contents of the object would be permitted
Password-Capability System
Implementation
• Special-purpose hardware designed and built
to implement the logical address space via a
set of ‘window registers’ which implemented a
segmented memory with individual
read/write/execute/limit/caching rights being
checked on each memory/cache reference
• Logical address space divided into 32 equally
sized windows which can each contain a view
of an object defined by a capability
• Separate logical address space for the
operating system kernel
Password-Capability System
Kernel Interface
• Conventional style supervisor call instruction
allows a trap into the kernel
• Parameters for the kernel calls passed on the
stack or via registers
• Kernel operations generally require a
capability, an operation to be specified, and
perhaps some other information depending
on the operation requested
• Some kernel calls affect the current process
and are used for instance to map objects into
the logical address space
Password-Capability System
Abstract Data Type Manager
• Type manager is an object containing
executable code implementing the type
• For information hiding type managers one
would normally make the object execute-only
• The type manager creates an instance of a
type by creating an object and sealing the
capability by XORing the password-2 field
with a secret seal (a secret number) before
returning the capability to the user
• The sealed capability cannot be used directly,
only by the type manager who can unseal it
Motivation for Walnut
• Specially built hardware is obsolete before
you finish building it
• Need to run on conventional platforms to
have a hope of keeping up with latest
processor performance and attracting users
• Needs to be easily ported to new platforms so
shouldn’t use platform dependent facilities
unless absolutely necessary
• Addresses some limitations of the original
Password-Capability System after user
experience with that system
Walnut
• Implemented on an Intel 80486
• No use of its segmentation hardware since
that would limit portability and there were not
enough segment registers for a useable
system anyway
• Page protection granularity rather than word
level granularity
• Execute access right not checked on initial
Walnut implementation since the hardware
only supported read/write protection bits
• Subprocess concept for exception handling
Walnut Logical Address Space
• Supports two areas for objects
– Small object area for small objects starting on
4-Kbyte boundaries
– Large object area for large objects startingg on
4-Mbyte boundaries
• Has an area reserved for the kernel
• Has a parameter page at a fixed location
where the kernel finds parameter
information for kernel calls
• Object semantics is different
– Objects define a maximum extent and a
maximum size, but may contain holes
Walnut Subprocesses
• A subprocess is NOT an execution thread
in the conventional sense. It is more like a
coroutine, never executing concurrently
with another subprocess of the process
• Each subprocess has its own stack pointer
and program counter but shares the logical
address space
• Messages can be directed to particular
subprocesses
• Subprocesses have priorities for scheduling
• Intended use is for exception / signal
handlers
Walnut Kernel Interface
• Subprocess 0 is the Walnut Kernel
• Typically set to a very high priority so that
other subprocesses can make kernel calls
by sending messages to subprocess 0
• Can invoke kernel calls on another process
by sending an appropriate message to
subprocess 0 of the other process
• Now that the kernel is just another
subprocess and needs a capability giving
the right to send it a message, one now has
fine grained control over kernel operations
Walnut Evaluation
• It works on off the shelf PCs
• Protection granularity is now page sized,
thus visible to the user and potentially liable
to change in new hardware
• Subprocesses allow finer control of access
to kernel calls
• Subprocesses are powerful enough to
perform the functions of sophisticated
priority interrupt or signal handlers
• Processes more uniformly integrated into
the virtual memory in that the current
process is no longer something special
Walnut Problem
• Omitting ‘execute only’ access right
checking from the initial Walnut
implementation for efficiency reasons due
to lack of hardware support was probably a
mistake and it should be put in despite the
awkwardness of implementation and its
performance cost
• Without such access checking, the elegant
implementation of abstract data type
managers and type instances is not so
easy to do
• Other mechanisms are however possible
Weaknesses of The PasswordCapability System and Walnut
• Fine for discretionary access control but not
adequate if one wants to implement a military
style Bell-LaPadula scheme in which you can
in effect combine capability lists and access
control lists in a dynamic way
• Fine for simple confinement models using the
locking mechanism but inadequate for more
sophisticated multi-level confinement where
the process may not be the right entity to
confine
Reasons for the weaknesses
• The Password-Capability System
implemented type managed modules through
a sealing mechanism which protected the
instance data from being manipulated except
via the type manager, but that was an implicit
link back to the appropriate code for the type
• You have capabilities for the instance and for
the type manager
• To add some mandatory security policy to an
instance you need to force a call to a security
module to check security say via an access
control list, before calling the type manager.
Solving The Problem
• What is required is for instance data to
contain an explicit link to the code that must
be invoked to gain access to the type
instance
• This is in a way contrary to the philosophy of
the system and hints at a segregated system
with capabilities to the type manager etc.
embedded in a protected area within the
instance
• A similar approach can be used for
confinement by replacing the logical address
space with explicit protected capability lists
What Next?
• A new password-capability based system
• Conventional hardware
– Although proper segmented address spaces
would solve many problems
• Address Walnut shortcomings
• Define an absolute minimum structure to
allow more sophisticated confinement and
mandatory code invokation based on
instances
• Wherever possible, do things at user code
level, not in the kernel.
• i.e. stay with the original philosophy
Should there be fundamental
philosophical changes made
to the conceptual bases of the
system?
• Some of the original and unusual aspects of
The Password-Capability System were
– Anonymity
– No system defined directories
– No concept of ownership
– No concept of ‘users’
– No way to have system recognized structured
organization of objects
Questions?