use title case for headers

4 files changed, 41 insertions, 41 deletions

diff --git a/blog/access-control.org b/blog/access-control.org
index 79e3039..3eace82 100644
--- a/blog/access-control.org
+++ b/blog/access-control.org
@@ -1,7 +1,7 @@
-* access control
+* Access Control
 On the Linux desktop, most people are running apps with zero access control enforced, meaning that running the Discord client for example, can ~rm -rf ${HOME}~ or slurp up your private data such as your ssh keys. This is not great, but there are several options available to address this problem.
 
-* example program
+* Example Program
 I'm going to use weechat as an example of a program that we want to isolate from the rest of the system. It's simple but not trivial, and touches a lot of commonly shared directories like ~XDG_CONFIG_DIR~, ~XDG_STATE_DIR~ and similar.
 
 At it's core, Weechat needs access to a few directories and the network. We will focus on the directories.
@@ -24,10 +24,10 @@ It also needs read-only access to some system files such as (assuming a merged-u
   /usr/share
 #+END_SRC
 
-* our options
+* Our Options
 There are multiple options available to do access control on Linux, but I'm going to cover namespaces (with bubblewrap), Apparmor and SELinux.
 
-** bubblewrap
+** Bubblewrap
 Bubblewrap is a small C utility used to setup mount namespaces for sandboxing and container purposes.
 
 Mount namespaces are a way to control processes views of mount points, meaning processes in different mount namespaces cannot see each others mounts. A simple example would be mounting a USB drive to ~/mnt/usb~. If you mount the USB drive in a separate mount namespace, other processes will not see anything mounted to ~/mnt/usb~ at all.
@@ -116,7 +116,7 @@ ID mapping is confusing for me personally, but ~bwrap~ has some flags to help yo
 
 ~bwrap~ can also unshare ipc, pid, net, uts and cgroup namespaces, which all work similar to the namespaces described above, and provide isolation for things beyond files which is also an important aspect of sandboxing.
 
-** apparmor
+** Apparmor
 Apparmor is a "Linux Security Module" (LSM), and a mandatory access control (MAC) system.
 
 MAC is different from discretionary access control (DAC) in that a central authority controls the rules, instead of owners of the resource.
@@ -166,31 +166,31 @@ The primary flaw is that apparmor is *path based* rather than *inode based*. Har
 
 By default, apparmor prevents you from being able to *execute* the paths you gave access to. There are a few ways to give *execute* permissions.
 
-*** execute modes
+*** Execute Modes
  - ~ix~ starts the subproc under the current profile
  - ~ux~ starts the subproc unconfined
  - ~px~ starts the subproc under a profile that matches the executable path
  - ~cx~ starts the subproc under a subprofile
 
-*** caveat
+*** Caveats
 Until Linux 6.17, apparmor will not be fully functional without Ubuntu kernel patches.
 
 The primary missing feature I am aware of is the ability to restrict access to unix sockets.
 
-** selinux
+** SELinux
 Selinux is another MAC based LSM, it's however quite different from apparmor.
 
-*** labels
+*** Labels
 Selinux access control works by labeling subjects (processes) and objects (files etc) with "types", this information is stored in the files xattrs, an example label is "~sys.id:sys.role:sys.subj:s0~".
 
 Unlike apparmor, Selinux is inode based rather than path based, so hardlinks can't be used as loopholes.
 
 The first part of the label is the *user*, the second is the *role* and the third is the *type*. Mostly we are going to ignore users and roles and focus on types for this.
 
-*** dssp5
+*** Dssp5
 This post is going to assume we are basing our policy [[https://salsa.debian.org/dgrift/dssp5/][dssp5]], a minimal and modular base policy that we create our own types on top of. [[https://salsa.debian.org/dgrift/dssp5/][dssp5]] provides the core types.
 
-*** built in types
+*** Built In Types
 [[https://salsa.debian.org/dgrift/dssp5/][dssp5]] provides many core types that we will build our policy on top of.
 
 An example of a core type is ~home.file~. This is a type applied to home directories such as ~/home/john~. There are many base types for various parts of the filesystem.
@@ -205,11 +205,11 @@ Here are some major built in types:
 
 There are also "subtypes" for some of these built in types like ~spool.var.file~ for ~/var/spool~.
 
-*** how do files get typed
-**** setfiles
+*** How Do Files Get Typed
+**** Setfiles
 Mount points will be labeled with ~setfiles~, and any new files created underneath that mount point should inherit the label by default. This is default label for files that don't have a filecon defined.
 
-**** filecon
+**** Filecon
 In Selinux policy you will define ~filecon~ expressions like this (ignore the other parts for now):
 
 #+BEGIN_SRC
@@ -221,7 +221,7 @@ In Selinux policy you will define ~filecon~ expressions like this (ignore the ot
 
 After compiling and loading the policy, you would use the built in ~restorecon~ command to apply these labels.
 
-**** type transitions
+**** Type Transitions
 Also files can change types via type transitions at runtime. An example for weechat, we want all of the runtime files weechat creates to be labeled ~agent.weechat~ or similar, so we define a type transition in the weechat selinux module:
 
 #+BEGIN_SRC
@@ -233,24 +233,24 @@ Also files can change types via type transitions at runtime. An example for weec
 
 Another example would be transitioning from one context to another when executing something. In our later policy, running the weechat executable causes a type transition from ~sys.subj~ to ~weechat.subj~.
 
-*** how do processes get typed
+*** How Do Processes Get Typed
 With dssp5, processes will start in the ~sys.subj~ context which is basically unconfined and has access to everything. Processes change types via type transitions or with ~runcon~. We will go over type transitions a bit more later when we define the weechat module.
 
 #+BEGIN_SRC
   (sidcontext init (sys.id sys.role sys.subj sys.lowlow)) ;; userspace_initial_context
 #+END_SRC
 
-*** cil overview
+*** Cil Overview
 Cil is the language we will write policy in. It's a simple sexpr based language, with namespaces, types, typeattributes (metatypes), macros and templates.
 
-**** cil types
+**** Cil Types
 We can define types like this:
 
 #+BEGIN_SRC
   (type foo)
 #+END_SRC
 
-**** cil namespaces
+**** Cil Namespaces
 In cil we will almost always be working in a namespace.
 
 We can define a namespace with the block keyword:
@@ -285,7 +285,7 @@ You access types with the ~.~ operator. A dot at the beginning of the expression
 
 We will make great use of namespaces in our policy!
 
-**** macros
+**** Macros
 Macros are sort of like functions. Macros "capture" local types similar to lambdas and interpolate parameters into expressions.
 
 #+BEGIN_SRC
@@ -302,7 +302,7 @@ Macros are sort of like functions. Macros "capture" local types similar to lambd
     (call .foo.test (qux)))
 #+END_SRC
 
-**** templates
+**** Templates
 Templates are blocks that are inherited by other blocks.
 
 Abstract blocks are blocks which only exist once they are inherited.
@@ -327,7 +327,7 @@ Hint: abstract blocks are very commonly used to define types, so you will often
 
 We will make great use of the built in templates for almost everything we do.
 
-**** type attributes
+**** Type Attributes
 Type attributes are like "metatypes". They are used to group types together for shared behaviour.
 
 An example here:
@@ -376,7 +376,7 @@ A good example for the usefulness of type attributes is the program ~userdel~, t
 
 Typeattributes are one of the most important things for abstracting out behavior. You can create hierarchies of types in a way similar to OOP.
 
-**** type transitions
+**** Type Transitions
 Type transitions are rules in policy that control how types change at runtime. A common desire would be to have files created by weechat end up with a weechat label, or entering a new context when executing something.
 
 I do not fully understand how these work internally, but I will show an example of how to do this:
@@ -396,16 +396,16 @@ I do not fully understand how these work internally, but I will show an example
 
 This will cause files created in the weechat context, under ~/var/run/${UID}~ to be transitioned into the ~agent.weechat.run.file~ type, rather than the "default" ~user.var.file~ (the default type depends on your policy, this is just an example).
 
-*** policy
+*** Policy
 Lets write some policy now!
 
-**** xdg directories
+**** XDG Directories
 
 We want to create some new types for the directories weechat requires access to.
 
 #+INCLUDE: "access-control/xdgfile.cil" src
 
-**** loading policy
+**** Loading Policy
 
 You can load dssp5 policy up with:
 
@@ -421,7 +421,7 @@ Next run ~restorecon~ to apply our new labels (this could take a while):
 
 If everything went as planned you should be able to use ~ls -alZ ${HOME}~ to see your new labels.
 
-**** weechat policy
+**** Weechat Policy
 
 Define policy for weechat itself:
 
@@ -431,12 +431,12 @@ In dssp5 you will notice that we rarely write ~allow~ rules directly, we use mac
 
 Selinux is by far the most verbose of the options I listed, but also the most powerful and flexible, and IMO the most fun.
 
-**** todo
+**** Todo
 For your real policy you want to create abstractions for common behaviour to cut down on the boilerplate.
 
 A large part of the weechat module could be abstracted out into a new .subj.common module. Common behavor like accessing your own files and accessing things that every process will need like the dynamic loader and system libraries.
 
 With dssp5 it's up to you to build up abstractions, it only provides a base.
 
-* questions
+* Questions
 If you have any questions or problems you can email me (my contact info is on my front page), or join the ~#selinux~ channel on [[https://irc.libera.chat]].
diff --git a/blog/gentoo-on-gcloud.org b/blog/gentoo-on-gcloud.org
index d826e53..2ab530e 100644
--- a/blog/gentoo-on-gcloud.org
+++ b/blog/gentoo-on-gcloud.org
@@ -1,8 +1,8 @@
-* gentoo on google cloud
+* Gentoo On Google Cloud
 
 Google Cloud only provides Debian and a few other operating system images by default, but does allow bringing your own ISO.
 
-** gentoo official qcow2 images
+** Gentoo Official QCOW2 Images
 
 The first thing I tried was booting one of Gentoo's official qcow2 images directly.
 
@@ -18,7 +18,7 @@ After doing these steps, I created a new vm instance with the Gentoo qcow2 image
 
 I am not exactly sure what is wrong with gcloud, but these images boot fine in qemu for me.
 
-** hijacking a debian image
+** Hijacking A Debian Image
 Instead of using one of the official Gentoo images, we decided to "hijack" one of gclouds already booting Debian images.
 
 To do this, I created a new instance using the default Debian boot disk, and then cloned the instance's disk while the instance was shut down. Then I booted the instance back up, and attached the clone'd disk to the instance.
@@ -31,6 +31,6 @@ The trick that got it to boot, was clearing out the old EFI binaries completely,
 
 After installing our new bootloader, I shut down the instance, detached the boot disk, and reattached the Gentoo disk as the new boot disk. Then booted into Gentoo!
 
-* tldr
+* TLDR
 
 To get it to boot, you hijack a working image by making a new rootfs on the rootfs partition, replace the kernel, initramfs and then the bootloader with a "removable" bootloader (aka ~grub-install --removable~).
diff --git a/blog/index.org b/blog/index.org
index 3f7f9b9..514b65e 100644
--- a/blog/index.org
+++ b/blog/index.org
@@ -1,6 +1,6 @@
-* gentoo on gcloud
+* Gentoo on Google Cloud
 
 [[https://jturnerusa.dev/blog/gentoo-on-gcloud.html][Installing Gentoo on a Google Cloud compute instance!]]
 
-* access control
+* Access Control
 [[https://jturnerusa.dev/blog/access-control.html][Access control methods]]
diff --git a/index.org b/index.org
index 0219f70..0feadf8 100644
--- a/index.org
+++ b/index.org
@@ -1,18 +1,18 @@
 * jturnerusa.dev
 Hello, my name is John Turner and I like to tinker with software and various computer related things.
 
-* contact
+* Contact
 I can be contacted at "jturner.usa@gmail.com".
 
-* projects
+* Projects
 Some of my projects can be viewed at [[https://jturnerusa.dev/cgit]].
 
-* blog
+* Blog
 Some blog posts can be seen at [[https://jturnerusa.dev/blog/index.html]].
 
-* keys
+* Keys
 
-** pgp
+** PGP
 Send me private messages with PGP if you'd like!
 
 [[https://jturnerusa.dev/keys/pgp/jturner.usa@gmail.com]]
@@ -32,7 +32,7 @@ u7DSW37j3OZzTtxQswEA70uff9WN+PmZWrJ3pkvjM9eJHA6xGxy2HRerw3BNJQE=
 -----END PGP PUBLIC KEY BLOCK-----
 #+END_SRC
 
-** ssh
+** SSH
 I sign my git commits with my ssh keys.
 
 [[https://jturnerusa.dev/keys/ssh/gentoo-pc]]