My undergraduate thesis on a capability based security system for a data-centric operating system.
adding daniels feedback
+50
-17
+25
-9
1-introduction.typ
+25
-9
1-introduction.typ
···
6
6
7
7
// talk about the standard unix abstractions
8
8
9
-
In mainstream operating systems, a
9
+
In mainstream operating systems, an
10
10
omnicient and all-powerful kernel enforces security policy at runtime.
11
11
// what am i trying to say here.
12
-
It acts as the bodyguard, holding all i/o and data protected unless the
12
+
It acts as the bodyguard, holding all I/O and data hostage unless the
13
13
requesting party has the authorization to access some resource. This tight
14
14
coupling of security policy and access mechanisms works well since any access
15
15
must be done through the kernel, so why not perform security checks
16
16
alongside accesses? However,
17
17
the enforcement of security policy starts getting complicated when we try
18
-
to separate the access mechanisms from the kernel. This problem arises
19
-
in a certain class of operating systems.
18
+
to separate the access mechanisms from the kernel.
19
+
20
+
//TODO: explain why this happens?
21
+
This problem arises in a certain class of operating systems.
20
22
21
23
== Data-Centric Operating Systems
22
24
25
+
//TODO: daniel feedback
26
+
// I would add a paragraph motivating the data-centric approach
27
+
// like why would i want the kernel out of the way?
28
+
23
29
Data-centric operating systems are defined by two principles @twizzler:
24
30
25
31
+ They provide direct, kernel-free, access to data.
26
32
27
33
+ They have a notion of pointers that are tied to the data they represent.
28
34
35
+
// then this paragrapch can focus on why removing the kernel
36
+
// from the access path is a security probjem
37
+
// maybe worth discussing how the access is tied to the mmu as well.
38
+
//
29
39
Mainstream operating systems fail to classify as data-centric operating
30
40
systems, as they rely on the kernel for all data access, and use virtualized
31
41
pointers per process to represent underlying data. The benefit of this "class"
···
37
47
== Capability Based Security Systems
38
48
39
49
40
-
// describe capability based security systems
41
-
//
42
-
// how they are different from earlier thingies
43
50
44
51
Capability-based security systems have a rich history in research, and offer
45
52
an alternative approach to security, in opposition to the Access Control Lists of prevalent OS's @linux_security.
···
49
56
of the kernel's involvement in the creation and management of security policy.
50
57
In a well-designed system, as we see in @twizsec and described later, this allows
51
58
users to completely create and manage security policy while the kernel is left to enforce
52
-
it. This paradigm permits kernel-free access of data, while also guaranteeing
53
-
security.
59
+
it.
60
+
61
+
//TODO: how? (via mmu + pagetable mappings programmed via the kernel) (which is still kernel-free for most data accesses)
62
+
This paradigm permits kernel-free access of data, while also guaranteeing
63
+
security.
64
+
65
+
//TODO: maybe add a bit about "unforgeable" tokens, cryptographic operations, why they are needed
66
+
67
+
54
68
55
69
56
70
···
64
78
Code can be found in this
65
79
#link("https://github.com/twizzler-operating-system/twizzler/issues/268")[Github
66
80
tracking issue].
81
+
82
+
//TODO: list pr's with a short summary of what each one accomplishes?
67
83
68
84
#load-bib(read("refs.bib"))
+15
-6
2-keypair.typ
+15
-6
2-keypair.typ
···
4
4
#mol-chapter("Key Pairs")
5
5
6
6
// what are keypair objects ?
7
+
// TODO: fix this fuckin sentence
7
8
Key pairs in Twizzler are representation of the cryptographic signing
8
-
schemes used to create a signed capability, as discussed in 3.1. We design
9
+
schemes used to create a signed capability, as discussed in 3.1.
10
+
11
+
12
+
We design
9
13
the keypair objects to be agnostic towards the underlying scheme to allow for
10
14
multiple schemes, as described in @twizzler. This also helps with backwards
11
15
compatibilty when adding new, more secure schemes, in the future. The keys
···
13
17
storage depending on object specification, and allows for keys themselves to
14
18
be treated as any other object and have security policy applied to them. This
15
19
allows for powerful primitives and rich expressiveness for describing secruity
20
+
//NOTE: elaborate or point forward to later
16
21
policy, while also being intuitive enough to construct basic policy easily.
17
22
18
23
···
21
26
The `SigningKey` struct is a fixed length byte array with a length field
22
27
and an enum specifying what algorithm that key should be interpreted as.
23
28
Currently we use the Elliptic Curve Digital Signature Algorithm (ECDSA) @ecdsa
29
+
//TODO: why are we talkin about the simplistic data representation without
30
+
// actually explaining the representation. maybe having a diagram would be useful?
24
31
to sign capabilities and verify them, but the simplistic data representation
25
-
allows for any arbitrary alogrithm to be used as long as the key can be
32
+
allows for any arbitrary algorithm to be used as long as the key can be
26
33
represented as bytes.
27
34
28
35
Additionally this specification allows for backward compatibility, allowing
···
31
38
of the buffer we store the key in. Currently we set the maximum size as 256
32
39
bytes, meaning if a future cryptographic signing scheme was to be created with
33
40
a key size larger than 256 bytes, we would have to drop backwards
34
-
compatibility. Sure this can be prevented now by setting the maximum size to
35
-
something larger, but thats a tradeoff between possible cryptographic schemes
41
+
compatibility. While this can be prevented now by setting the maximum size to
42
+
something larger, it ends up being tradeoff between possible cryptographic schemes
36
43
vs the real on-disk cost of larger buffers.
37
44
38
45
== Compartmentalization
39
46
// how they can be used to sign multiple objects (compartmentalization)
40
47
41
-
To create an object in twizzler, you specify the id of a verifying key
48
+
To create an object in twizzler, you specify the ID of a verifying key
42
49
object so the kernel knows which key to use to verify any
43
50
capabilities permitting access to the object. Since keys are represented as objects
44
51
in twizzler, security policy applies on them as well, creating satisfying
45
52
solutions in regards to key management.
46
53
47
-
Suppose for instance we have Alice on Twizzler, and all users on twizzler have
54
+
Suppose for instance we have Alice on Twizzler, and all users on Twizzler have
48
55
a "user-root" keypair that allows for them to create an arbitrary number of
49
56
objects. Also suppose that access to this user-root keypair is protected by
50
57
some login program, where only alice can log in. This means that Alice
···
53
60
access the keys required to create new signatures allowing permissions into
54
61
*her* objects. It forms an elegant solution for key management without
55
62
the involvement of the kernel.
63
+
64
+
// nice, we should talk more about this
56
65
57
66
58
67
#load-bib(read("refs.bib"))
thesis.pdf
thesis.pdf
This is a binary file and will not be displayed.
+10
-2
thesis.typ
+10
-2
thesis.typ
···
23
23
degree: "Computer Engineering B.S."
24
24
)
25
25
26
+
// DANIEL feedback
27
+
// overall great start, I'd extend the intro a little bit, its a litte sparse
28
+
// and could use a few more things, same thing with future work and conclusion.
29
+
//
30
+
// run a spell check
31
+
//
32
+
// more feedback throughout, feel free to take or ignore
33
+
26
34
#mol-abstract[
27
35
Traditional operating systems permit data access through the kernel, applying
28
36
security policy as a part of that pipeline. The Twizzler operating system
29
37
flips that relationship on its head, focusing on an approach where data
30
-
access is a first-class citizen, getting rid of the kernel as a middleman. With
31
-
this data-centric approach, it requires us to rethink how security policy
38
+
access is a first-class citizen, getting rid of the kernel as a middleman.
39
+
This data-centric approach requires us to rethink how security policy
32
40
interacts with users and the kernel. In this thesis, I present the design and
33
41
implementation of core security primitives in Twizzler. Then I evaluate the
34
42
security model with a basic and advanced scenario, as well as microbenchmarks