My undergraduate thesis on a capability based security system for a data-centric operating system.
more daniel additions
+60
-11
+19
-5
1-introduction.typ
+19
-5
1-introduction.typ
···
5
5
#mol-chapter("Introduction")
6
6
7
7
// talk about the standard unix abstractions
8
-
9
8
In mainstream operating systems, an
10
9
omnicient and all-powerful kernel enforces security policy at runtime.
11
10
// what am i trying to say here.
···
13
12
requesting party has the authorization to access some resource. This tight
14
13
coupling of security policy and access mechanisms works well since any access
15
14
must be done through the kernel, so why not perform security checks
16
-
alongside accesses? However,
15
+
alongside accesses?
16
+
17
+
18
+
This coupling gets challenged as soon as one tries to decouple access mechanisms
19
+
from the kernel, as we see in Twizzler.
20
+
Twizzler is a research operating system focused on new programming paradigms
21
+
22
+
However,
17
23
the enforcement of security policy starts getting complicated when we try
18
-
to separate the access mechanisms from the kernel.
24
+
to separate the access mechanisms from the kernel.
19
25
20
-
//TODO: explain why this happens?
21
-
This problem arises in a certain class of operating systems.
26
+
// TODO: maybe give a brief introduction to twizzler?
27
+
28
+
29
+
22
30
31
+
//TODO: explain why this happens?
23
32
== Data-Centric Operating Systems
33
+
24
34
25
35
//TODO: daniel feedback
26
36
// I would add a paragraph motivating the data-centric approach
···
31
41
+ They provide direct, kernel-free, access to data.
32
42
33
43
+ They have a notion of pointers that are tied to the data they represent.
44
+
45
+
By defenition, they require the removal of the kernel from the access path.
46
+
This is desirable since it would remove the kernel overhead for data accesses,
47
+
resulting in pure performance gains for heavy I/O applications.
34
48
35
49
// then this paragrapch can focus on why removing the kernel
36
50
// from the access path is a security probjem
+8
-1
3-cap.typ
+8
-1
3-cap.typ
···
5
5
6
6
// define a capability
7
7
Capabilities are the atomic unit of security in Twizzler, acting as tokens of
8
+
//NOTE: point forward towards security contexts?
8
9
protections granted to a process, allowing it to access some object in the ways
9
10
it describes. Colloquially a capability is defined as permissions and
10
11
a unique object to which those permissions apply, but in Twizzler we add
···
28
29
//
29
30
== Signature
30
31
The signature is what determines the validity of the capability. The
31
-
only possible signer of some capability is who ever has permissions to the
32
+
only possible signer of some capability is who ever has permissions to read the
32
33
signing key object, or the kernel itself. The signature is built up of a array with
33
34
a maximum length and a enum representing what type of cryptographic scheme
34
35
was used to create it; quite similar to the keys mentioned previously.
···
46
47
but in the context of this thesis it is sufficient to think of them as a region of allowed
47
48
memory access.
48
49
50
+
// interesting! I think this model you describe is more general, if we were to add a SWITCH_CTX permission bit...
51
+
// something to think about
52
+
49
53
== Flags
50
54
Currently, flags in capabilities are used to specify which hashing algorithm to use to form a message to be signed. We allow for multiple algorithms to be used to
51
55
allow for backward capability when newer, more efficient hashing algorithms are created.
···
55
59
form the message for the signature, but there's plenty of bits left to use.
56
60
We hope for future work to develop more expressive ways of using capabilities, i.e. Decentralized Information Flow Control, as specified in
57
61
6.1.
62
+
63
+
//TODO: maybe worth discussing delegations if only to describe how they could be
64
+
// extended from capabilities (as a future work ofc)
58
65
59
66
60
67
#load-bib(read("refs.bib"))
+16
-3
4-secctx.typ
+16
-3
4-secctx.typ
···
2
2
3
3
#mol-chapter("Security Contexts")
4
4
5
-
Security Contexts are objects that processes attach to in-order to inherit the
5
+
Security Contexts are objects that threads attach to in-order to inherit the
6
6
permissions inside the context. The contexts store capabilities, allowing for userspace
7
7
programs to add capabilities to contexts, and kernel space to efficiently search
8
-
through them to determie whether a process has the permissions to perform a memory access.
8
+
through them to determine whether a process has the permissions to perform a memory access.
9
9
10
10
== Base
11
11
···
30
30
this map for lookup while the user interacts with this map to indicate the insertion, removal, or modification of
31
31
a capability.
32
32
33
+
//TODO: talk about the map in memory, and about how its flat, might be worth discussing in the context
34
+
// of not storing virtual address pointers.
35
+
33
36
=== Masks
34
37
Masks act as a restraint on the permissions this context can provide for some targeted object.
35
38
This allows for more expressive security policy, such as being able to quickly restrict
···
60
63
61
64
The enforcement of security policy in Twizzler happens on page fault when trying to access
62
65
a new object @twizzler. Upon fault, the kernel inspects the target object and identifies the
63
-
default permissnons of that object. Then the kernel checks if the currently active
66
+
default permissions of that object. Then the kernel checks if the currently active
64
67
security context for the accessing thread has either cached or capabilities that provide
65
68
permissions. If default permissions + the active context permissions arent enough to
66
69
permit the access, the kernel then checks each of the inactive contexts to see if they
···
76
79
The original Twizzler paper @twizzler, and the following security paper
77
80
go into more detail about the philosophy behind why enforcement works this way, such as the
78
81
performance benefits of letting programs access objects directly without kernel involvement, etc.
82
+
83
+
//TODO: may be worth summarizing a few more bits here
84
+
// doesnt have to be super detailed or anything but its better to havea ... thing tie together
85
+
// than and a parathere with "etc"
86
+
//
87
+
// eg. recovering posix semantics and why thats desirable, allowing for
88
+
// "contained" threads, ...
89
+
//
90
+
// basically talk more about stuff from the original twizzler paper about why this style of enforcement
91
+
// is good, its fine to benefit
79
92
80
93
#load-bib(read("refs.bib"))
+12
-1
5-results.typ
+12
-1
5-results.typ
···
32
32
== Micro Benchmarks
33
33
Additionally, we have microbenchmarks of core security operations in Twizzler. All
34
34
benchmarks were run with a Ryzen 5 2600, with Twizzler virtualized in QEMU. Unfortunately
35
+
//TODO: do not say they they should be the same :sob:, instead say that finding
36
+
// the difference between virtualized performance and actual performance is future work
35
37
I ran out of time to perform benchmarks on bare metal, but they should be the same, if
36
38
not more, performant.
37
39
38
40
=== Kernel
39
-
40
41
There a couple of things we benchmark inside the kernel, including core cryptographic
41
42
operations like signature generation and verification, as well as the total time it takes
42
43
to verify a capability.
44
+
45
+
//TODO: is this with SIMD in kernel? maybe worth discussing this nuance
46
+
//
47
+
// how many times did you run the experimnt and how were the stats calculated.
48
+
//
49
+
// could be interesting to compare signature verification cost as the amount of data
50
+
// to verify goes up
51
+
// my_note: (wouldnt this only be applicable towards delegations though since others are always
52
+
// done properly)
53
+
//
43
54
#figure(
44
55
table(
45
56
columns: (auto, auto),
+5
-1
6-conclusion.typ
+5
-1
6-conclusion.typ
···
2
2
3
3
#mol-chapter("Conclusion")
4
4
5
+
//TODO: So, this is more a summary. Which is good to have here, but
6
+
// you'll want to have some conclusions -- e.g. What did you learn (e.g. about the
7
+
// cost of the operations)
5
8
In short we provide a general overview of the critical security
6
9
components for security system in Twizzler, along with
7
10
implementation details and desgin descisions. The evaluation programs show how
···
11
14
12
15
== Future Works
13
16
17
+
// TODO: Maybe go into more detail here. There's a number of things that are discussed
18
+
// as future work throughout that could use a couple sentences each here.
14
19
In the future I hope to take the primitives created during my thesis, and apply them towards
15
20
the implementation of Decentralized Information Flow Control, as described in @flume, into
16
21
the Twizzler security model. Additionally I would love to see how the current security model
···
19
24
20
25
21
26
== Acknowledgements
22
-
23
27
I couldn't have done the work for this thesis and for Twizzler if it wasn't for the
24
28
support I've recieved from my advisor Owen Arden and my technical mentor Daniel Bittman! I
25
29
owe both of you so much, not just for the class credit but also for how much I've learned in
thesis.pdf
thesis.pdf
This is a binary file and will not be displayed.