My undergraduate thesis on a capability based security system for a data-centric operating system.
1#import "template.typ": *
2
3#mol-chapter("Capabilities")
4
5
6// define a capability
7Capabilities are the atomic unit of security in Twizzler, acting as tokens of
8//NOTE: point forward towards security contexts?
9protections that allow a process to access an object in the ways it describes. More
10information about how capabilities interact with processes can be found in section 4.2.
11Colloquially a capability is defined as permissions and a unique object to which
12those permissions apply, but in Twizzler we add the signature component to allow
13the kernel to validate that the security policy was created by an authorized
14party.
15
16Thus, a Capability is represented as follows:
17
18
19```rust
20struct Cap {
21 target: ObjID, // Object ID this capability grants access to.
22 accessor: ObjID, // Security context ID in which this capability resides.
23 prots: Protections, // Specific access rights this capability grants.
24 flags: CapFlags, // Cryptographic configuration for capability validation.
25 gates: Gates, // Constraints on where permisions are applied.
26 revocation: Revoc, // Specifies when this capability is invalid, i.e. expiration.
27 sig: Signature, // The signature.
28}
29```
30
31//
32== Signature
33The signature is what determines the validity of the capability. The
34only possible signer of some capability is who ever has permissions to read the
35signing key object, or the kernel itself. The signature is built up of an array with
36a maximum length and an enum representing what type of cryptographic scheme
37was used to create it; quite similar to the keys mentioned in section 2.
38The fields of the capability are serialized and hashed to form the message that gets signed,
39and then stored in the signature field. Currently we support Blake3 and
40Sha256 as hashing algorithms.
41
42// what do i want to talk about regarding signatures?
43
44== Gates
45Gates act as a limited entry point into objects. If a capability has a non-trivial gate,
46which is made up of an offset field, and a length field, the kernel will read that and ensure
47that any memory accesses into that object are within the gate bounds. The original Twizzler
48paper @twizzler describes gates as a way to perform IPC, and calls between distinct programs,
49but in the context of this thesis it is sufficient to think of them as a region of allowed
50memory access.
51
52// interesting! I think this model you describe is more general, if we were to add a SWITCH_CTX permission bit...
53// something to think about
54
55== Flags
56Currently, flags in capabilities are used to specify which hashing algorithm was
57used
58to form the message that was signed. We allow multiple algorithms to be used
59to allow for backward capability when newer, more efficient hashing algorithms
60are created.
61
62The flags inside a capability is a bitmask providing information about distinct
63feautures of that capability. Currently they only convey the hashing algoritmn
64but there's plenty of bits left to use. We hope for future work to develop more
65expressive ways of using capabilities through the flags.
66// maybe worth discussing delegations if only to describe how they could be
67// extended from capabilities (as a future work ofc)
68//
69// lowkey tuah lazy to do dis rn, so maybe later, plus i havent talked about
70// them at all so im sure daniel is just recomending this as a way to add
71// content here, so ill see.
72
73
74#load-bib(read("../refs.bib"))
75
76
77
78
79