My undergraduate thesis on a capability based security system for a data-centric operating system.
whole buncha work
+560
-35
+6
1-introduction.typ
+6
1-introduction.typ
···
46
46
47
47
== Our Contributions
48
48
49
+
In this thesis, I detail the fundamentals of security in the Twizzler
50
+
operating system, and discuss how I implement and refine some of the high
51
+
level ideas described in @twizzler and an early draft of a Twizzler security
52
+
paper. Additionally we evaluate these systems inside kernel and user space,
53
+
with comparsions to micro-benchmarks done with an older version of twizzler.
54
+
49
55
// describe the twizzler opensource project
50
56
//
51
57
// my contribution of the existing plan for a security system
+42
-2
2-keypair.typ
+42
-2
2-keypair.typ
···
4
4
#mol-chapter("Key Pairs")
5
5
6
6
// what are keypair objects ?
7
+
Key pairs are the Signing and Verifying keys used to create Capabilities.
8
+
We design the keypair objects to be agnostic towards what cryptographic
9
+
schemes are underneath, allowing for the underlying algorithm to be changed
10
+
@twizzler. The keys themselves are stored inside of objects, allowing for
11
+
persistent or volatile storage depending on object specification. It also
12
+
allows for the keys to fall under the security system, meaning that signing
13
+
keys can be protected by a different keypair, forming this chain of trust.
14
+
15
+
16
+
7
17
8
18
// how are they represented in twizzler ?
9
19
10
20
== Abstraction
11
21
12
-
// the abstraction layer to represent multiple signing schemes
22
+
The `SigningKey` struct is a fixed length byte array with a length field
23
+
and an enum specifying what algorithm that key should be interpreted as.
24
+
Currently we use the Elliptic Curve Digital Signature Algorithm (ECDSA)
25
+
@ecdsa to sign capabilities and verify them, but the simplistic dat
26
+
arepresentation allows for any arbitrary alogrithm to be used as long as
27
+
the key can be represented as bytes.
13
28
29
+
Additionally this specification allows
30
+
for backward compatibility, allowing for an outdated signing scheme to be used in
31
+
support of older programs / files. An existing drawback for backward compatibility is the
32
+
maximum size of the buffer we store the key in. Currently we set the maximum size as 256 bytes,
33
+
meaning if a future cryptographic signing scheme was to be found with a private key size
34
+
larger than 256 bytes, we would have to drop backwards compatibility. Sure this
35
+
can be prevented by setting the maximum size to something larger, but that a tradeoff
36
+
between possible cryptographic schemes vs the real on-disk cost of larger buffers.
14
37
15
38
== Compartmentalization
16
39
// how they can be used to sign multiple objects (compartmentalization)
17
-
//
18
40
41
+
To create an object in twizzler, you specify the id of a verifying key
42
+
object so the kernel knows which key to use to verify any
43
+
capabilities permitting access to the object. You can also specify
44
+
default protections for an object or create a capability with the signing
45
+
key and any desired permissions.
19
46
47
+
The neat thing about this design is that you can use a single keypair in-order to use
48
+
any arbitrary amount of objects. This results in the possibility of finegrained
49
+
access control to semantic groupings of objects.
50
+
51
+
An example could be a colletion of objects holding files for a class, and grouping all of them
52
+
under the same key.
20
53
21
54
55
+
// what the fuck am i trying to say
56
+
Now restricting access to that one key prevents the usage of that key to create
57
+
any new objects?
58
+
59
+
// all it does is make creation easier, since you only need one pair, it doesnt
60
+
// restrict capabilities or whatever. It's just a benefit since we dont have to worry
61
+
// about managing a keypair for every single object
22
62
23
63
#load-bib(read("refs.bib"))
+39
-2
3-cap.typ
+39
-2
3-cap.typ
···
4
4
5
5
6
6
// define a capability
7
+
Capabilities are the atomic unit of security in Twizzler, acting as tokens of
8
+
protections granted to a process, allowing it to access some object in the ways
9
+
it describes. A Capability is built up of the following fields.
7
10
8
-
// the atomic unit of security
11
+
12
+
```
13
+
struct Cap {
14
+
target: ObjID, // Object ID this capability grants access to
15
+
accessor: ObjID, // Security context ID in which this capability resides
16
+
prots: Protections, // Specific access rights this capability grants
17
+
flags: CapFlags, // Cryptographic configuration for capability validation
18
+
gates: Gates, // Additional constraints on when this capability can be used
19
+
revocation: Revoc, // Specifies when this capability is invalid, i.e. expiration.
20
+
sig: Signature, // The signature inside the capability
21
+
}
22
+
```
23
+
24
+
//
25
+
== Signature
26
+
The signature inside is what determines the validity of this capability. The
27
+
only possible signer of some capability is who ever has permissions to the
28
+
signing key object, or the kernel. In this way, if the signer decides to
29
+
make the signing key private to them, no other entity can administer this
30
+
signature for this capability. The signature is built up of a array with
31
+
a maximum length and a enum representing what type of cryptographic scheme
32
+
was used to create it; quite similar to the keys mentioned previously.
33
+
The message being signed to form the signature is the bytes of each of the
34
+
fields inside the capability being hashed. There is support for multiple
35
+
hashing algorithms as described in 3.1.
36
+
37
+
38
+
// what do i want to talk about regarding signatures?
9
39
10
40
== Gates
11
41
12
42
== Flags
43
+
Currently flags in capabilities are used to specify which hashing algorithm to use in order
44
+
to form a message to be signed. We allow for multiple algorithms to be used in order to
45
+
allow for backwards capability when newer, more efficient hashing algorithms are created.
13
46
14
-
== Signature
47
+
There is also plenty of space left in the bitmap, allowing for future work to develop more
48
+
expressive ways of using capabilities, such as planned future work to implement information
49
+
flow control into the twizzler security system.
50
+
51
+
15
52
16
53
#load-bib(read("refs.bib"))
+49
-16
refs.bib
+49
-16
refs.bib
···
1
1
@inproceedings{twizzler,
2
-
author = {Daniel Bittman and Peter Alvaro and Pankaj Mehra and Darrell D. E.
3
-
Long and Ethan L. Miller},
4
-
title = {Twizzler: a {Data-Centric} {OS} for {Non-Volatile} Memory},
5
-
booktitle = {2020 USENIX Annual Technical Conference (USENIX ATC 20)},
6
-
year = {2020},
7
-
isbn = {978-1-939133-14-4},
8
-
pages = {65--80},
9
-
url = {https://www.usenix.org/conference/atc20/presentation/bittman},
10
-
publisher = {USENIX Association},
11
-
month = jul,
2
+
author = {Daniel Bittman and Peter Alvaro and Pankaj Mehra and Darrell D. E.
3
+
Long and Ethan L. Miller},
4
+
title = {Twizzler: a {Data-Centric} {OS} for {Non-Volatile} Memory},
5
+
booktitle = {2020 USENIX Annual Technical Conference (USENIX ATC 20)},
6
+
year = {2020},
7
+
isbn = {978-1-939133-14-4},
8
+
pages = {65--80},
9
+
url = {https://www.usenix.org/conference/atc20/presentation/bittman},
10
+
publisher = {USENIX Association},
11
+
month = jul,
12
12
}
13
13
14
14
@inproceedings{linux_security,
15
-
author = {Zhai, Gaoshou and Li, Yaodong},
16
-
year = {2009},
17
-
month = {01},
18
-
pages = {58 - 61},
19
-
title = {Analysis and Study of Security Mechanisms inside Linux Kernel},
20
-
doi = {10.1109/SecTech.2008.17},
15
+
author = {Zhai, Gaoshou and Li, Yaodong},
16
+
year = {2009},
17
+
month = {01},
18
+
pages = {58 - 61},
19
+
title = {Analysis and Study of Security Mechanisms inside Linux Kernel},
20
+
doi = {10.1109/SecTech.2008.17},
21
+
}
22
+
23
+
24
+
@article{ecdsa,
25
+
author = {Johnson, Don and Menezes, Alfred and Vanstone, Scott},
26
+
title = {The Elliptic Curve Digital Signature Algorithm (ECDSA)},
27
+
year = {2001},
28
+
issue_date = {August 2001},
29
+
publisher = {Springer-Verlag},
30
+
address = {Berlin, Heidelberg},
31
+
volume = {1},
32
+
number = {1},
33
+
issn = {1615-5262},
34
+
url = {https://doi.org/10.1007/s102070100002},
35
+
doi = {10.1007/s102070100002},
36
+
abstract = {The Elliptic Curve Digital Signature Algorithm (ECDSA) is the
37
+
elliptic curve analogue of the Digital Signature Algorithm (DSA).
38
+
It was accepted in 1999 as an ANSI standard and in 2000 as IEEE
39
+
and NIST standards. It was also accepted in 1998 as an ISO
40
+
standard and is under consideration for inclusion in some other
41
+
ISO standards. Unlike the ordinary discrete logarithm problem and
42
+
the integer factorization problem, no subexponential-time
43
+
algorithm is known for the elliptic curve discrete logarithm
44
+
problem. For this reason, the strength-per-key-bit is
45
+
substantially greater in an algorithm that uses elliptic curves.
46
+
This paper describes the ANSI X9.62 ECDSA, and discusses related
47
+
security, implementation, and interoperability issues.},
48
+
journal = {Int. J. Inf. Secur.},
49
+
month = aug,
50
+
pages = {36–63},
51
+
numpages = {28},
52
+
keywords = {Key words: Signature schemes --- Elliptic curve cryptography ---
53
+
DSA --- ECDSA},
21
54
}
+5
-5
refs.fdb_latexmk
+5
-5
refs.fdb_latexmk
···
1
1
# Fdb version 4
2
-
["pdflatex"] 1747262537.07689 "/home/suri/dev/school/cse195/thesis/refs.bib" "refs.pdf" "refs" 1747262537.21239 2
3
-
"/home/suri/dev/school/cse195/thesis/refs.bib" 1747262536.98598 753 f89392e8126180e235f45ea7a3de865f ""
4
-
"/nix/store/mdmi3lq496xbfxw7ixvkvv2c3ykdfcjk-texlive-2024-env/share/texmf-var/web2c/pdftex/pdflatex.fmt" 1 3353350 ed70dbc3ea5f7d39b612736943eedf66 ""
5
-
"/nix/store/mdmi3lq496xbfxw7ixvkvv2c3ykdfcjk-texlive-2024-env/share/texmf-var/web2c/texmf.cnf" 1 43655 498ae5f8cc45791715ea18c3a41168b3 ""
2
+
["pdflatex"] 1748296325.39774 "/home/suri/dev/school/cse195/thesis/refs.bib" "refs.pdf" "refs" 1748296325.55299 2
3
+
"/home/suri/dev/school/cse195/thesis/refs.bib" 1748296325.29732 2189 0f6a879b7c76aa53b30fa0eb3341b491 ""
4
+
"/nix/store/sl1ys83ijvmdnhryfa3150p0s2rnybfm-texlive-2024-env/share/texmf-var/web2c/pdftex/pdflatex.fmt" 1 3353354 03e2e815cb988c5cf638af704cef84bd ""
5
+
"/nix/store/sl1ys83ijvmdnhryfa3150p0s2rnybfm-texlive-2024-env/share/texmf-var/web2c/texmf.cnf" 1 43655 e642192c1e39bfbb4f9f3b20c60bf2ae ""
6
6
"refs.aux" 1747249710.22753 32 3985256e7290058c681f74d7a3565a19 "pdflatex"
7
-
"refs.bib" 1747262536.98598 753 f89392e8126180e235f45ea7a3de865f ""
7
+
"refs.bib" 1748296325.29732 2189 0f6a879b7c76aa53b30fa0eb3341b491 ""
8
8
(generated)
9
9
"refs.aux"
10
10
"refs.log"
+2
-2
refs.fls
+2
-2
refs.fls
···
1
1
PWD /home/suri/dev/school/cse195/thesis
2
-
INPUT /nix/store/mdmi3lq496xbfxw7ixvkvv2c3ykdfcjk-texlive-2024-env/share/texmf-var/web2c/texmf.cnf
3
-
INPUT /nix/store/mdmi3lq496xbfxw7ixvkvv2c3ykdfcjk-texlive-2024-env/share/texmf-var/web2c/pdftex/pdflatex.fmt
2
+
INPUT /nix/store/sl1ys83ijvmdnhryfa3150p0s2rnybfm-texlive-2024-env/share/texmf-var/web2c/texmf.cnf
3
+
INPUT /nix/store/sl1ys83ijvmdnhryfa3150p0s2rnybfm-texlive-2024-env/share/texmf-var/web2c/pdftex/pdflatex.fmt
4
4
INPUT /home/suri/dev/school/cse195/thesis/refs.bib
5
5
OUTPUT refs.log
+221
-6
refs.log
+221
-6
refs.log
···
1
-
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024/nixos.org) (preloaded format=pdflatex 1980.1.1) 14 MAY 2025 15:42
1
+
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024/nixos.org) (preloaded format=pdflatex 1980.1.1) 26 MAY 2025 14:52
2
2
entering extended mode
3
3
\write18 enabled.
4
4
%&-line parsing enabled.
···
441
441
the way to recover is to insert both the forgotten and the
442
442
deleted material, e.g., by typing `I$}'.
443
443
444
+
! Missing $ inserted.
445
+
<inserted text>
446
+
$
447
+
l.22
448
+
449
+
I've inserted a begin-math/end-math symbol since I think
450
+
you left one out. Proceed, with fingers crossed.
451
+
452
+
453
+
Overfull \hbox (101.10962pt too wide) in paragraph at lines 14--22
454
+
[]$[]\OML/cmm/m/it/10 ecurity; author \OT1/cmr/m/n/10 =
455
+
[]
456
+
457
+
458
+
Overfull \hbox (171.02025pt too wide) in paragraph at lines 14--22
459
+
[]\OML/cmm/m/it/10 ; year \OT1/cmr/m/n/10 =
460
+
[]
461
+
462
+
463
+
Overfull \hbox (64.0024pt too wide) in paragraph at lines 14--22
464
+
[]\OML/cmm/m/it/10 ; month \OT1/cmr/m/n/10 =
465
+
[]
466
+
467
+
468
+
Overfull \hbox (49.78932pt too wide) in paragraph at lines 14--22
469
+
[]\OML/cmm/m/it/10 ; pages \OT1/cmr/m/n/10 =
470
+
[]
471
+
472
+
473
+
Overfull \hbox (65.72632pt too wide) in paragraph at lines 14--22
474
+
[]\OML/cmm/m/it/10 ; title \OT1/cmr/m/n/10 =
475
+
[]
476
+
477
+
478
+
Overfull \hbox (306.94754pt too wide) in paragraph at lines 14--22
479
+
[]\OML/cmm/m/it/10 ; doi \OT1/cmr/m/n/10 =
480
+
[]
481
+
482
+
483
+
Overfull \hbox (113.78154pt too wide) in paragraph at lines 14--22
484
+
[]\OML/cmm/m/it/10 ;$
485
+
[]
486
+
487
+
488
+
! LaTeX Error: Missing \begin{document}.
489
+
490
+
See the LaTeX manual or LaTeX Companion for explanation.
491
+
Type H <return> for immediate help.
492
+
...
493
+
494
+
l.24 @
495
+
article{ecdsa,
496
+
You're in trouble here. Try typing <return> to proceed.
497
+
If that doesn't work, type X <return> to quit.
498
+
499
+
Missing character: There is no @ in font nullfont!
500
+
Missing character: There is no a in font nullfont!
501
+
Missing character: There is no r in font nullfont!
502
+
Missing character: There is no t in font nullfont!
503
+
Missing character: There is no i in font nullfont!
504
+
Missing character: There is no c in font nullfont!
505
+
Missing character: There is no l in font nullfont!
506
+
Missing character: There is no e in font nullfont!
507
+
Missing character: There is no e in font nullfont!
508
+
Missing character: There is no c in font nullfont!
509
+
Missing character: There is no d in font nullfont!
510
+
Missing character: There is no s in font nullfont!
511
+
Missing character: There is no a in font nullfont!
512
+
Missing character: There is no , in font nullfont!
513
+
Missing character: There is no a in font nullfont!
514
+
Missing character: There is no u in font nullfont!
515
+
Missing character: There is no t in font nullfont!
516
+
Missing character: There is no h in font nullfont!
517
+
Missing character: There is no o in font nullfont!
518
+
Missing character: There is no r in font nullfont!
519
+
Missing character: There is no = in font nullfont!
520
+
Missing character: There is no J in font nullfont!
521
+
Missing character: There is no o in font nullfont!
522
+
Missing character: There is no h in font nullfont!
523
+
Missing character: There is no n in font nullfont!
524
+
Missing character: There is no s in font nullfont!
525
+
Missing character: There is no o in font nullfont!
526
+
Missing character: There is no n in font nullfont!
527
+
Missing character: There is no , in font nullfont!
528
+
Missing character: There is no D in font nullfont!
529
+
Missing character: There is no o in font nullfont!
530
+
Missing character: There is no n in font nullfont!
531
+
Missing character: There is no a in font nullfont!
532
+
Missing character: There is no n in font nullfont!
533
+
Missing character: There is no d in font nullfont!
534
+
Missing character: There is no M in font nullfont!
535
+
Missing character: There is no e in font nullfont!
536
+
Missing character: There is no n in font nullfont!
537
+
Missing character: There is no e in font nullfont!
538
+
Missing character: There is no z in font nullfont!
539
+
Missing character: There is no e in font nullfont!
540
+
Missing character: There is no s in font nullfont!
541
+
Missing character: There is no , in font nullfont!
542
+
Missing character: There is no A in font nullfont!
543
+
Missing character: There is no l in font nullfont!
544
+
Missing character: There is no f in font nullfont!
545
+
Missing character: There is no r in font nullfont!
546
+
Missing character: There is no e in font nullfont!
547
+
Missing character: There is no d in font nullfont!
548
+
Missing character: There is no a in font nullfont!
549
+
Missing character: There is no n in font nullfont!
550
+
Missing character: There is no d in font nullfont!
551
+
Missing character: There is no V in font nullfont!
552
+
Missing character: There is no a in font nullfont!
553
+
Missing character: There is no n in font nullfont!
554
+
Missing character: There is no s in font nullfont!
555
+
Missing character: There is no t in font nullfont!
556
+
Missing character: There is no o in font nullfont!
557
+
Missing character: There is no n in font nullfont!
558
+
Missing character: There is no e in font nullfont!
559
+
Missing character: There is no , in font nullfont!
560
+
Missing character: There is no S in font nullfont!
561
+
Missing character: There is no c in font nullfont!
562
+
Missing character: There is no o in font nullfont!
563
+
Missing character: There is no t in font nullfont!
564
+
Missing character: There is no t in font nullfont!
565
+
Missing character: There is no , in font nullfont!
566
+
Missing character: There is no t in font nullfont!
567
+
Missing character: There is no i in font nullfont!
568
+
Missing character: There is no t in font nullfont!
569
+
Missing character: There is no l in font nullfont!
570
+
Missing character: There is no e in font nullfont!
571
+
Missing character: There is no = in font nullfont!
572
+
Missing character: There is no T in font nullfont!
573
+
Missing character: There is no h in font nullfont!
574
+
Missing character: There is no e in font nullfont!
575
+
Missing character: There is no E in font nullfont!
576
+
Missing character: There is no l in font nullfont!
577
+
Missing character: There is no l in font nullfont!
578
+
Missing character: There is no i in font nullfont!
579
+
Missing character: There is no p in font nullfont!
580
+
Missing character: There is no t in font nullfont!
581
+
Missing character: There is no i in font nullfont!
582
+
Missing character: There is no c in font nullfont!
583
+
Missing character: There is no C in font nullfont!
584
+
Missing character: There is no u in font nullfont!
585
+
Missing character: There is no r in font nullfont!
586
+
Missing character: There is no v in font nullfont!
587
+
Missing character: There is no e in font nullfont!
588
+
Missing character: There is no D in font nullfont!
589
+
Missing character: There is no i in font nullfont!
590
+
Missing character: There is no g in font nullfont!
591
+
Missing character: There is no i in font nullfont!
592
+
Missing character: There is no t in font nullfont!
593
+
Missing character: There is no a in font nullfont!
594
+
Missing character: There is no l in font nullfont!
595
+
Missing character: There is no S in font nullfont!
596
+
Missing character: There is no i in font nullfont!
597
+
Missing character: There is no g in font nullfont!
598
+
Missing character: There is no n in font nullfont!
599
+
Missing character: There is no a in font nullfont!
600
+
Missing character: There is no t in font nullfont!
601
+
Missing character: There is no u in font nullfont!
602
+
Missing character: There is no r in font nullfont!
603
+
Missing character: There is no e in font nullfont!
604
+
Missing character: There is no A in font nullfont!
605
+
Missing character: There is no l in font nullfont!
606
+
Missing character: There is no g in font nullfont!
607
+
Missing character: There is no o in font nullfont!
608
+
Missing character: There is no r in font nullfont!
609
+
Missing character: There is no i in font nullfont!
610
+
Missing character: There is no t in font nullfont!
611
+
Missing character: There is no h in font nullfont!
612
+
Missing character: There is no m in font nullfont!
613
+
Missing character: There is no ( in font nullfont!
614
+
Missing character: There is no E in font nullfont!
615
+
Missing character: There is no C in font nullfont!
616
+
Missing character: There is no D in font nullfont!
617
+
Missing character: There is no S in font nullfont!
618
+
Missing character: There is no A in font nullfont!
619
+
Missing character: There is no ) in font nullfont!
620
+
Missing character: There is no , in font nullfont!
621
+
Missing character: There is no y in font nullfont!
622
+
Missing character: There is no e in font nullfont!
623
+
Missing character: There is no a in font nullfont!
624
+
Missing character: There is no r in font nullfont!
625
+
Missing character: There is no = in font nullfont!
626
+
Missing character: There is no 2 in font nullfont!
627
+
Missing character: There is no 0 in font nullfont!
628
+
Missing character: There is no 0 in font nullfont!
629
+
Missing character: There is no 1 in font nullfont!
630
+
Missing character: There is no , in font nullfont!
631
+
Missing character: There is no i in font nullfont!
632
+
Missing character: There is no s in font nullfont!
633
+
Missing character: There is no s in font nullfont!
634
+
Missing character: There is no u in font nullfont!
635
+
Missing character: There is no e in font nullfont!
636
+
! Missing $ inserted.
637
+
<inserted text>
638
+
$
639
+
l.28 issue_
640
+
date = {August 2001},
641
+
I've inserted a begin-math/end-math symbol since I think
642
+
you left one out. Proceed, with fingers crossed.
643
+
644
+
645
+
LaTeX Warning: Command \textendash invalid in math mode on input line 50.
646
+
647
+
648
+
LaTeX Warning: Command \textendash invalid in math mode on input line 50.
649
+
650
+
! Extra }, or forgotten $.
651
+
l.54 }
652
+
653
+
I've deleted a group-closing symbol because it seems to be
654
+
spurious, as in `$x}$'. But perhaps the } is legitimate and
655
+
you forgot something else, as in `\hbox{$x}'. In such cases
656
+
the way to recover is to insert both the forgotten and the
657
+
deleted material, e.g., by typing `I$}'.
658
+
444
659
)
445
660
! Emergency stop.
446
661
<*> /home/suri/dev/school/cse195/thesis/refs.bib
···
449
664
450
665
451
666
Here is how much of TeX's memory you used:
452
-
18 strings out of 473203
453
-
480 string characters out of 5692202
454
-
391988 words of memory out of 5000000
455
-
23365 multiletter control sequences out of 15000+600000
667
+
21 strings out of 473203
668
+
500 string characters out of 5692202
669
+
395988 words of memory out of 5000000
670
+
23368 multiletter control sequences out of 15000+600000
456
671
558837 words of font info for 36 fonts, out of 8000000 for 9000
457
672
1141 hyphenation exceptions out of 8191
458
-
18i,2n,20p,127b,59s stack positions out of 10000i,1000n,20000p,200000b,200000s
673
+
18i,3n,20p,125b,59s stack positions out of 10000i,1000n,20000p,200000b,200000s
459
674
! ==> Fatal error occurred, no output PDF file produced!
thesis.pdf
thesis.pdf
This is a binary file and will not be displayed.
+195
thesis.txt
+195
thesis.txt
···
1
+
Twizzler-Security
2
+
A Capability-Based Security System for Twizzler
3
+
4
+
BSc Thesis
5
+
written by
6
+
Surendra Jammishetti
7
+
under the supervision of Owen B. Arden, and submitted to the
8
+
Examinations Board in partial fulfilment of the requirements for the degree of
9
+
10
+
Computer Engineering B.S.
11
+
at the University of California, Santa Cruz.
12
+
13
+
Date of the public defence:
14
+
15
+
Members of the Thesis Committee:
16
+
17
+
August 28, 2005
18
+
19
+
Dr. Peter Alvaro
20
+
Dr. Andi Quinn
21
+
22
+
Abstract
23
+
whatevea lowkey not even sure what to write
24
+
25
+
Contents
26
+
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
27
+
1.1 Data Centric Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
28
+
1.2 Capability Based Security Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
29
+
1.3 Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
30
+
2 Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
31
+
2.1 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
32
+
2.2 Compartmentalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
33
+
3 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
34
+
3.1 Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
35
+
3.2 Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
36
+
3.3 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
37
+
4 Security Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
38
+
4.1 Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
39
+
5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
40
+
6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
41
+
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
42
+
43
+
1
44
+
45
+
Chapter 1
46
+
47
+
Introduction
48
+
In mainstream operating systems, security policy is enforced at runtime by a omnicient and all
49
+
powerful kernel. It acts as the bodyguard, holding all i/o and data protected unless the requesting
50
+
party has the authorization to access some resource. This tight coupling of security policy and
51
+
access mechanisms works great since the kernel is always there and the only way to access anything
52
+
through it. However the enforcement of security policy starts getting complicated when we try to
53
+
seperate the access mechanisms from the kernel.
54
+
55
+
1.1 Data Centric Operating Systems
56
+
Data centric operating systems are defined by two principles [Bit+20]:
57
+
1. Provide direct, kernel-free, access to data.
58
+
2. A notion of pointers that are tied to the data they represent.
59
+
Mainstream operating systems fail to classify as data-centric operating systems, as they rely on the
60
+
kernel for all data access, and use virtualized pointers per process to represent underlying data. The
61
+
benefit of this “class” of operating systems comes from the low overhead for data manipulation, due
62
+
to the lack of kernel involvement. However our previous security model fails to operate here as, by
63
+
defenition, the kernel cannot be infront of accesses to data.
64
+
65
+
1.2 Capability Based Security Systems
66
+
Capability based security systems utilize capabilities, a finegrained
67
+
68
+
1.3 Our Contributions
69
+
In this thesis, I detail the fundamentals of security in the Twizzler operating system, and discuss
70
+
how I implement and refine some of the high level ideas described in [Bit+20] and an early draft of
71
+
a Twizzler security paper. Additionally we evaluate these systems inside kernel and user space, with
72
+
comparsions to micro-benchmarks done with an older version of twizzler.
73
+
74
+
2
75
+
76
+
Chapter 2
77
+
78
+
Key Pairs
79
+
Key pairs are the Signing and Verifying keys used to create Capabilities. We design the keypair
80
+
objects to be agnostic towards what cryptographic schemes are underneath, allowing for the underlying algorithm to be changed [Bit+20]. The keys themselves are stored inside of objects, allowing
81
+
for persistent or volatile storage depending on object specification. It also allows for the keys to
82
+
fall under the security system, meaning that signing keys can be protected by a different keypair,
83
+
forming this chain of trust.
84
+
85
+
2.1 Abstraction
86
+
The SigningKey struct is a fixed length byte array with a length field and an enum specifying
87
+
what algorithm that key should be interpreted as. Currently we use the Elliptic Curve Digital
88
+
Signature Algorithm (ECDSA) [JMV01] to sign capabilities and verify them, but the simplistic dat
89
+
arepresentation allows for any arbitrary alogrithm to be used as long as the key can be represented
90
+
as bytes.
91
+
Additionally this specification allows for backward compatibility, allowing for an outdated
92
+
signing scheme to be used in support of older programs / files. An existing drawback for backward
93
+
compatibility is the maximum size of the buffer we store the key in. Currently we set the maximum
94
+
size as 256 bytes, meaning if a future cryptographic signing scheme was to be found with a private
95
+
key size larger than 256 bytes, we would have to drop backwards compatibility. Sure this can be
96
+
prevented by setting the maximum size to something larger, but that a tradeoff between possible
97
+
cryptographic schemes vs the real on-disk cost of larger buffers.
98
+
99
+
2.2 Compartmentalization
100
+
To create an object in twizzler, you specify the id of a verifying key object so the kernel knows which
101
+
key to use to verify any capabilities permitting access to the object. You can also specify default
102
+
protections for an object or create a capability with the signing key and any desired permissions.
103
+
The neat thing about this design is that you can use a single keypair in-order to use any arbitrary
104
+
amount of objects. This results in the possibility of finegrained access control to semantic groupings
105
+
of objects.
106
+
An example could be a colletion of objects holding files for a class, and grouping all of them
107
+
under the same key.
108
+
Now restricting access to that one key prevents the usage of that key to create any new objects?
109
+
110
+
3
111
+
112
+
Chapter 3
113
+
114
+
Capabilities
115
+
Capabilities are the atomic unit of security in Twizzler, acting as tokens of protections granted
116
+
to a process, allowing it to access some object in the ways it describes. A Capability is built up of
117
+
the following fields.
118
+
struct Cap {
119
+
target: ObjID,
120
+
121
+
// Object ID this capability grants access to
122
+
123
+
accessor: ObjID,
124
+
125
+
// Security context ID in which this capability resides
126
+
127
+
prots: Protections, // Specific access rights this capability grants
128
+
flags: CapFlags,
129
+
130
+
// Cryptographic configuration for capability validation
131
+
132
+
gates: Gates,
133
+
134
+
// Additional constraints on when this capability can be used
135
+
136
+
revocation: Revoc,
137
+
138
+
// Specifies when this capability is invalid, i.e. expiration.
139
+
140
+
sig: Signature,
141
+
142
+
// The signature inside the capability
143
+
144
+
}
145
+
146
+
3.1 Signature
147
+
The signature inside is what determines the validity of this capability. The only possible signer of
148
+
some capability is who ever has permissions to the signing key object, or the kernel. In this way,
149
+
if the signer decides to make the signing key private to them, no other entity can administer this
150
+
signature for this capability. The signature is built up of a array with a maximum length and a
151
+
enum representing what type of cryptographic scheme was used to create it; quite similar to the
152
+
keys mentioned previously. The message being signed to form the signature is the bytes of each of
153
+
the fields inside the capability being hashed. There is support for multiple hashing algorithms as
154
+
described in 3.1.
155
+
156
+
3.2 Gates
157
+
3.3 Flags
158
+
Currently flags in capabilities are used to specify which hashing algorithm to use in order to form a
159
+
message to be signed. We allow for multiple algorithms to be used in order to allow for backwards
160
+
capability when newer, more efficient hashing algorithms are created.
161
+
There is also plenty of space left in the bitmap, allowing for future work to develop more
162
+
expressive ways of using capabilities, such as planned future work to implement information flow
163
+
control into the twizzler security system.
164
+
165
+
4
166
+
167
+
Chapter 4
168
+
169
+
Security Contexts
170
+
4.1 Map
171
+
172
+
5
173
+
174
+
Chapter 5
175
+
176
+
Results
177
+
178
+
6
179
+
180
+
Chapter 6
181
+
182
+
Conclusion
183
+
184
+
7
185
+
186
+
Bibliography
187
+
[Bit+20] Bittman D, Alvaro P, Mehra P, Long DDE, Miller EL. Twizzler: a Data-Centric OS for
188
+
Non-Volatile Memory. In:. 2020 USENIX Annual Technical Conference (USENIX ATC
189
+
20), USENIX Association; 2020, pp. 65–80.
190
+
[JMV01] Johnson D, Menezes A, Vanstone S. The Elliptic Curve Digital Signature Algorithm
191
+
(ECDSA). Int J Inf Secur 2001;1:36–63. https://doi.org/10.1007/s102070100002.
192
+
193
+
8
194
+
195
+