Update 2024-07-30-configuration-management.markdown

  - caught typos
  - added monospace formatting of keywords

_posts/2024-07-30-configuration-management.markdown

@@ -7,7 +7,7 @@ author: Phil Day
 ---
 All systems rely on some form of configuration data.
 Fully immutable systems, where configuration is baked in at build time, may work for container based environments where re-deployment is relatively easy, but in other systems the configuration interface forms a significant part of the attack surface, and misconfiguration, whether accidental or malicious, is a major sources of security vulnerabilities.
-For example the recent CrowdStrike outage was caused by a bug in an in-kernel parser that crashed when given an new configuration value.  
+For example the recent CrowdStrike outage was caused by a bug in an in-kernel parser that crashed when given a new configuration value.  
 
 The solution in many cases is to create an often complex trust model around and within the configuration interface to limit and control configuration changes, where the complexity itself adds to the threat profile.
 The threat profile is further increased when we consider the need to process serialised data which may itself be compromised.
@@ -26,18 +26,18 @@ The compartment ensures memory violations have no impact on the broker or any ot
 Each parser has its own static sealed capability granting it the right to register with the broker as the parser for a specific item type.
 Running as stateless isolated sidecars to the broker ensures the integrity of the parsers; the only interface to a parser is via a sentry guarded callback that it registers with the broker, and registration is based on the content of tokens that only the broker can unseal.
 Build time [auditing](https://cheriot.org/book/top-concepts-top.html#_auditing_firmware_images) can ensure that parsers do not call any other compartments.
-In the context of the CrowdStrike issue the impact of the parser bug would have been fully contained within the parer compartment; the system wouldn't have been updatable, but it would have remained available.   
+In the context of the CrowdStrike issue the impact of the parser bug would have been fully contained within the parser compartment; the system wouldn't have been updatable, but it would have remained available.   
 
 This pattern of implementing strongly defined trust boundaries, treating all data as untrusted regardless of its origin, and recognising that the data may be harmful even to try and parse, is aligned with the [principles-based guidance](https://www.ncsc.gov.uk/collection/cross-domain-solutions) published by the National Cyber Security Centre (NCSC) for cross domain operations.
 In this case each CHERIoT compartment can be considered to be operating as a separate trust domain.
 
-The demo also makes extensive use of the [permissions](https://cheriot.org/book/top-concepts-top.html#permissions) available on capabilities;  For example the broker removes all permissions except Load(Read) from the pointer to the serialised data it passes to the parser.
-Not only does this prevent the parser from unintentionally modifying its input, but it also prevents it from capturing it (no Global permission) or dereferencing it (no LoadStoreCapability).
-It also removes all permissions except Store(Write) from the pointer passed to hold the parsed value.
+The demo also makes extensive use of the [permissions](https://cheriot.org/book/top-concepts-top.html#permissions) available on capabilities;  For example the broker removes all permissions except `Load(Read)` from the pointer to the serialised data it passes to the parser.
+Not only does this prevent the parser from unintentionally modifying its input, but it also prevents it from capturing it (no `Global` permission) or dereferencing it (no `LoadStoreCapability`).
+It also removes all permissions except `Store(Write)` from the pointer passed to hold the parsed value.
 With no persistent heap space allocation available to the parser we can therefore be sure that the parsed value is only derived from the values in the serialised input and constants in the parser’s code.
 
-To ensure that configuration values remain immutable the broker removes the Store(Write) permission from the pointer once the parser has populated the data.
+To ensure that configuration values remain immutable the broker removes the `Store(Write)` permission from the pointer once the parser has populated the data.
 As there is no mechanism in the architecture to add permission back into a capability, there is simply no subsequent access from within the broker or anywhere that can then modify the value.
-The broker also removes the LoadStoreCapability permission, so that it is not possible to dereference from the configuration value even if a parser was somehow fooled into including a pointer.
+The broker also removes the `LoadStoreCapability` permission, so that it is not possible to dereference from the configuration value even if a parser was somehow fooled into including a pointer.
 
-The combination of compartments, sealed capabilities, and fine grained control of  permissions to protect and isolate the parser and its output is something that’s simply not possible on a conventional architecture.
+The combination of compartments, sealed capabilities, and fine grained control of permissions to protect and isolate the parser and its output is something that’s simply not possible on a conventional architecture.