fix markdown sec-blueprint

Signed-off-by: Ronan <ronan.lemartret@iot.bzh>

5 files changed, 346 insertions, 301 deletions

diff --git a/sec-blueprint/01-overview.md b/sec-blueprint/01-overview.md
index 9ee1670..c0134fb 100644
--- a/sec-blueprint/01-overview.md
+++ b/sec-blueprint/01-overview.md
@@ -16,34 +16,21 @@ layout: techdoc
 ## Introduction
 ### Abstract
 
+This document describes how it is possible to create reasonably secured connected cars using already available Open Source components.  
+The complexity attached to such project is clearly exposed for each step and may seem a quite heavy reading.  
+Fortunately ready made solutions are coming on the market (Open Source and Proprietary), enabling short cuts for many of us.
 
-This document describes how it is possible to create reasonably secured
-connected cars using already available Open Source components. The
-complexity attached to such project is clearly exposed for each step and
-may seem a quite heavy reading. Fortunately ready made solutions are
-coming on the market (Open Source and Proprietary), enabling short cuts
-for many of us.
-
-The documentation mostly focusses on the embedded side of the problem leaving the cloud
-components and manufacturing processes for further study.
+The documentation mostly focusses on the embedded side of the problem leaving the cloud components and manufacturing processes for further study.
 
 ### The risk is real
 
-Connected cars, to be accepted by users and keeping under control
-liability of the Automotive Industry will have to solve many issues
-ranging from physical, direct, and remote and indirect cloud attacks. A
-large section of unsolved technical security challenges, lies in car
-connectivity to user owned devices and well as to cloud.
-
-The Automotive Industry, by opposition to those operating in cloud and
-mobiles businesses, has little experience of security issues and no long
-return of experience. Proven solutions derived from the IT world are for
-most of them, inapplicable.
+Connected cars, to be accepted by users and keeping under control liability of the Automotive Industry will have to solve many issues ranging from physical, direct, and remote and indirect cloud attacks.  
+A large section of unsolved technical security challenges, lies in car connectivity to user owned devices and well as to cloud.  
+The Automotive Industry, by opposition to those operating in cloud and mobiles businesses, has little experience of security issues and no long return of experience.  
+Proven solutions derived from the IT world are for most of them, inapplicable.
 
-For many people the Cyber Security risk for the Automotive industry is
-still at best not understood and unfortunately more often, simply
-ignored. If the Fiat-Chrysler cyber car jacking has forced the industry
-to open their eyes, it is just a beginning.
+For many people the Cyber Security risk for the Automotive industry is still at best not understood and unfortunately more often, simply ignored.  
+If the Fiat-Chrysler cyber car jacking has forced the industry to open their eyes, it is just a beginning.
 
 -   24 Jul 2015 Hacking a radio in a car:  
     *"… the computer systems built into Fiat Chrysler cars: the flaw can
@@ -57,7 +44,7 @@ to open their eyes, it is just a beginning.
     ramsomware, or cyber terrorism using cars as weapon if nothing is
     done.  
 
-As malicious hackers or terrorists are smart and well organised, we know
+As malicious hackers or terrorists are smart and well organised, we know 
 that if we let them enter a system, even by a side door, they will work
 they way to the more juicy part of the system to monetise their work.
 
@@ -71,8 +58,8 @@ that tracking a mobile source will be more complex.
 ## Scope 
 Designing Connected cars without enabling a high level of security is
 not acceptable and will be soon a key market requirement for any
-respectable automotive company.
-AGL is aimaing at providing a reasonable level of security by default.
+respectable automotive company.  
+AGL is aimaing at providing a reasonable level of security by default.  
 The level of default security will evolve with the time and future releases to align with market expectations and needs.
 
 In order to converge on such an open question, we need to take
@@ -96,8 +83,8 @@ The assumptions selected are the following:
     run non attended.
 
 We can see that in such configuration, the base OS (kernel&middleware)
-represents a well guarded entry point for a malicious hacker. The
-combination of trusted boot, integrity enforcement and rootfs in ro,
+represents a well guarded entry point for a malicious hacker.  
+The combination of trusted boot, integrity enforcement and rootfs in ro,
 creates a set a garded walls to anyone, who would try to modify valid
 code on the product.
 
@@ -112,31 +99,34 @@ any compromised code.
 
 We will start by reducing the surface of attack by designing a product
 without open backdoors (e.g. cars drivers do not need a ssh connection
-nor tcpdump, so why to install the such development code on the image,
+nor tcpdump), so why to install the such development code on the image,
 and continue by reducing the capabilities which can be claimed by any
-code to the minimum required. This can be done by running the code with
-a non administrator’s user ID (non root) and by removing the unrequired
-capabilities and file access at code launch via Mandatory Access Control
-(MAC) and the Posix Capabilities.  
+code to the minimum required.  
+This can be done by running the code with a non administrator’s user ID 
+(non root) and by removing the unrequired capabilities and file access 
+at code launch via Mandatory Access Control (MAC) and the Posix Capabilities.  
 In the case of Smack, the general concept is to associate different
-label to specific code. As the MAC label cannot be changed by the
-process itself, it enables the security rules set to enforce the respect
-of the predefine code behaviour. Code with connects to the outside world
+label to specific code.  
+As the MAC label cannot be changed by theprocess itself, it enables the security rules set to enforce the respect
+of the predefine code behaviour.  
+Code with connects to the outside world
 by any mean, should first benefit of these special security
-configurations. The default policy should be good enough cover the
-security needs of most non connecting code.
+configurations.  
+The default policy should be good enough cover the security needs of most non connecting code.
 
 Once the surface of attack is reduced, you need to reduce possible
-damage when a malicious user will have found his way in. *Please
-remember that in security the question is not to know if someone will
+damage when a malicious user will have found his way in.  
+*Please remember that in security the question is not to know if someone will
 break in, but rather when, how you will detect it, and how to limit
 potential damages.*
 
 In this phase we will take care to limit options for a malicious user to
 move sideways and activate code that would help him to get more control
-over the system. We will pay a detailed attention to any code which can
+over the system.  
+We will pay a detailed attention to any code which can
 grant more privileges, change MAC label, create new user, install new
-Apps or update. Those types of code are normally called from a very
+Apps or update.  
+Those types of code are normally called from a very
 limited entry points in the system and once again the MAC system is your
 best friend when it comes to restrict activation from valid vector.
 
diff --git a/sec-blueprint/05-security-concepts.md b/sec-blueprint/05-security-concepts.md
index 114bc8b..5ddfe5b 100644
--- a/sec-blueprint/05-security-concepts.md
+++ b/sec-blueprint/05-security-concepts.md
@@ -16,13 +16,17 @@ layout: techdoc
 ## Security Principles
 When connecting a car to the internet, not only we create a mobile entry
 point to our private life, we also relocate our entry doors anywhere in
-the world. Neither all places on this planet are nice nor safe, nor are
-the people. The locks and alarms on cars, will give only a fake
+the world.
+
+Neither all places on this planet are nice nor safe, nor are
+the people.  
+The locks and alarms on cars, will give only a fake
 impression of security once that internet connection has entered the
 place.
 
 Internet enables the worse of human side to get access to private
-domains. If we are not careful, it will likely be invaded in a very
+domains.  
+If we are not careful, it will likely be invaded in a very
 short time following connection..
 
 **So, connected cars security must be designed as a military vehicle
@@ -30,7 +34,8 @@ which would be deployed in a high risk zone even when designing cars for
 out towns and villages**:
 
 -   Physical access to the car should not be a white card to hack
-    the system. Most cars sleep in the streets and public car parks where physical
+    the system.  
+    Most cars sleep in the streets and public car parks where physical
     accessibility is easy.
 -   Known defect should be corrected by SW update in real time, without a return to
     home or garage.
@@ -40,8 +45,8 @@ out towns and villages**:
 -   Connectivity between the various domains should be restricted to the
     minimal set required for their operation.
 -   Software loaded in cars and in the cloud should be vetted in
-    accordance with its capability to access critical resources. The
-    vetting authority must be controllable, enforceable and revocable.
+    accordance with its capability to access critical resources.  
+    The vetting authority must be controllable, enforceable and revocable.
 -   Inside each domain, sub domains should be created to limit even
     more, the nuisances capabilities of a successful malicious code.
 -   Software or devices not wetted should never be able to access any
@@ -52,52 +57,56 @@ authorise is strictly forbidden”,also known as ‘white listing’ policy.**
 
 We all understand those concepts, and nevertheless reports still show
 that very little people care about implementing protection against those
-risks yet. As a consequence most Connected Car projects are coming on
-the market with major security holes. It will take some time *(and
-likely some catastrophes)* for the Automotive Industry to clean up the
+risks yet.  
+As a consequence most Connected Car projects are coming on
+the market with major security holes.  
+It will take some time *(and likely some catastrophes)* for the Automotive Industry to clean up the
 pre-cyber security awareness designed products.
 
 The complexity induced by a security framework requires serious effort
-on the design side and complexifies the code execution. Fortunately our
-modern CPUs, which are very fast and ernergy efficient, can reduce this overhead
+on the design side and complexifies the code execution.  
+Fortunately our modern CPUs, which are very fast and ernergy efficient, can reduce this overhead
 to very acceptable extra work load on the computing and energy
 sub-systems.
 
 The challenge of Connected Cars is very similar to embedded devices
-in general. Within AGL we are defining solutions, which can enable this
+in general.  
+Within AGL we are defining solutions, which can enable this
 new market to emerge without requiring each product design to be
-chaperoned by security experts. *The world does not hold enough security
-experts to even overview even a few percent of the projects that are required
+chaperoned by security experts.  
+*The world does not hold enough security experts to even overview even a few percent of the projects that are required
 to create all connected devices that will be launched in the next 10
 years.*
 
 If embedded developers must implement complex security models
 without, having neither the time nor the skills, to architecture them
 correctly, *they can only succeed by reusing ready made trusted
-solutions*. Fortunately Connected Cars are based on some flavour of
+solutions*.  
+Fortunately Connected Cars are based on some flavour of
 Linux operating system which has, due to its long serving years in many
 critical domains, a large offering of security options.
 
 AGL only focus on the security facilities offered under
-Linux operating system for the connected car market.
+Linux operating system for the connected car market.  
 Non Linux Operating systems which can also be present in a connected car, are not covered by AGL platform security model.
 
 ## Strategy
-There is no miracle solution. When deciding which security strategy, you
+There is no miracle solution.  
+When deciding which security strategy, you
 will need, first to try to evaluate all the possible attack vectors,
 then to define your priorities and your limits.
 
 Even if today complexity is mostly in the software (SW), we still need
-some hardware (HW) to run it. Securing the HW is a very complex task
-which fortunately is likely yet not required for Connected Cars. I will
-not open more the topic here. Nevertheless applying a healthy design
-attitude by reducing obvious direct risk vectors (debug serial connector
+some hardware (HW) to run it.  
+Securing the HW is a very complex task which fortunately is likely yet not required for Connected Cars.  
+I will not open more the topic here.  
+Nevertheless applying a healthy design attitude by reducing obvious direct risk vectors (debug serial connector
 wired in production, tracks with clear communication channel easy
 accessible on PCB, …) should be done.
 
 Would your automotive project requires a more protected HW, you will
-find plenty of literature on that topic. I personally like this
-relatively old (2004) paper from J Grand as an introduction to the
+find plenty of literature on that topic.  
+I personally like this relatively old (2004) paper from J Grand as an introduction to the
 domain.  
 http://www.grandideastudio.com/wp-content/uploads/secure\_embed\_paper.pdf
 
@@ -110,21 +119,22 @@ On the SW side, the most efficient model is to work by layer :
     requires more than a simple trusted boot.  
     A strategy to control the integrity of the software and its
     configuration is required.
--   Be able to change (upgrade) the software to correct a newly
-    discovered risk.  
-    Assuming that the system will never be broken is an utopia. The
-    right strategy is to plan how to recover from the discovering of a
+-   **Be able to change (upgrade) the software to correct a newly
+    discovered risk.**  
+    Assuming that the system will never be broken is an utopia.  
+    The right strategy is to plan how to recover from the discovering of a
     new security issue to avoid its propagation.  
     *This upgrade mechanism must be particularly solid has it has to be
     capable of being executed on a compromised system without the
     support of a skilled operator.*
 -   **Only select trusted Linux drivers.**  
     In Linux, drivers are executed with the same privilege level than
-    the Kernel itself. I short a malicious or hacked driver is an
-    uncontrolled open door to the hart of the system. Only vetted driver
-    should be used and any complexity unique to the platform should be
-    pushed in the user space domain. This remark is particularly
-    important when introducing drivers that are connecting with the
+    the Kernel itself.  
+    I short a malicious or hacked driver is an
+    uncontrolled open door to the hart of the system.  
+    Only vetted driver should be used and any complexity unique to the platform should be
+    pushed in the user space domain.  
+    This remark is particularly important when introducing drivers that are connecting with the
     outside world.  
     Ideally dynamic driver integration after boot should be banned even
     if that would limit the flexibility of hot plug for USB devices.  
@@ -134,19 +144,20 @@ On the SW side, the most efficient model is to work by layer :
     https://www.isoc.org/isoc/conferences/ndss/11/pdf/3\_1.pdf
 -   **Isolate the core of the system from the middleware.**  
     By default the protection on Unix type systems (and so Linux) is
-    done by allocating the user a set of access rights. The side effect
-    is that any code running under a given name can access all the
-    resources that is given to that user. Furthermore it is possible at
-    any time to further expend this access to other users. *As most of
-    code in traditional embedded software run with the Administrator
+    done by allocating the user a set of access rights.  
+    The side effect is that any code running under a given name can access all the
+    resources that is given to that user.  
+    Furthermore it is possible at any time to further expend this access to other users.  
+    *As most of code in traditional embedded software run with the Administrator
     privilege (root) we foresee the danger of this traditional
-    embedded model. Fortunately Linux provides a Security model
-    called LSM.* (
+    embedded model.  
+    Fortunately Linux provides a Security model called LSM.* (
     https://en.wikipedia.org/wiki/Linux\_Security\_Modules)  
     It allows to create an access strategy which is not controlled by
-    the user but rather by the system configuration. Multiple front end
-    are available to control LSM and that will be studied a bit later in
-    this paper. This allows to create a Mandatory Access Control (MAC)
+    the user but rather by the system configuration.  
+    Multiple front end are available to control LSM and that will be studied a bit later in
+    this paper.  
+    This allows to create a Mandatory Access Control (MAC)
     which is a powerful tools to avoid compromised code to gain access
     to extra resources to propagate further.  
     Other restriction based on the c-groups, the Posix capabilities and
@@ -156,15 +167,16 @@ On the SW side, the most efficient model is to work by layer :
     IoS and Android phones have initiated the Apps model and nowadays
     launching a product which cannot be extended by Apps (from a closed
     or open Store) after the creation of the device is a risky
-    marketing strategy. While the model of Apps loaded from an open
-    store is reserved to a very small category of mass consumer devices,
+    marketing strategy.  
+    While the model of Apps loaded from an open store is reserved to a very small category of mass consumer devices,
     the capability to load Apps after the creation of the initial SW is
     a very attractive way to reduce the time to market as well as the
     reaction time to changing market demand.  
     In particular it would allow car manufacturers, to customise the car
     SW, individually on the production line, to the buyer wish.  
     *By design Apps are created with a quite loose coupling with the
-    core SW. The default Linux DAC (Discretionary Access Model) is not
+    core SW.  
+    The default Linux DAC (Discretionary Access Model) is not
     the most reliable for limiting the access to the system capabilities
     to the minimum required.*  
     Associating the validation of the origin of an App to the resource
@@ -214,28 +226,29 @@ device, is the expected one.
 ## Read Only root file system.
 
 In most embedded system the core OS is under control of the device
-manufacturer. *A very simple and efficient way to limit opportunities to
+manufacturer.  
+*A very simple and efficient way to limit opportunities to
 get the core OS and middle-ware to be modified by a malicious code, is
-to store it on a read only partition*. Even if that is not 100%
-bulletproof it seriously complexifies the level of required knowledge to
+to store it on a read only partition*.  
+Even if that is not 100% bulletproof it seriously complexifies the level of required knowledge to
 break into the OS and greatly eases, the implementation of a recovery
 strategy.
 
 In order to enable some local persistent changes such as those required
 to register some network or locale configurations, an overlay can be
-created for some directories. Since Linux 4.0, the kernel supports by
-default OverlayFS which provides that facility and support the extended
+created for some directories.  
+Since Linux 4.0, the kernel supports by default OverlayFS which provides that facility and support the extended
 file attributes required by file base MAC such as SELinux and Smack.  
 https://github.com/torvalds/linux/commit/e9be9d5e76e34872f0c37d72e25bc27fe9e2c54c
 
 ## Code Integrity during execution
 
 In the embedded world it is quite acceptable to restrict the end user to
-operate the system as designed. We can take profit of this favorable
-position, to limit the capabilities of a malicious applications to
+operate the system as designed.  
+We can take profit of this favorable position, to limit the capabilities of a malicious applications to
 change our Operating System (OS) after the protected initialisation
-(trusted boot). This can be done *by activating an integrity enforcement
-such as IMA/EVM on all the core OS.*  
+(trusted boot).  
+This can be done *by activating an integrity enforcement such as IMA/EVM on all the core OS.*  
 http://sourceforge.net/p/linux-ima/wiki/Home/
 
 In short IMA allows the kernel to check that a file has not been changed
@@ -248,8 +261,9 @@ Two types of labels are available :
 -   simple
 
 The signed labels are reserved for code or data which are static and
-provide the best level of protection. The signing tool remains external
-of the device. The simple hashes are reserved for code which can be
+provide the best level of protection.  
+The signing tool remains external of the device.  
+The simple hashes are reserved for code which can be
 install dynamically and the hash can be recalculated on the fly by the
 OS providing a lesser level of protection.
 
@@ -261,7 +275,8 @@ in the HW security sub-system.
 ## Update and Ugrade
 
 The integrity enforcement does not allow immutable files to be updated
-on line. The Integrity system would detect the violation and block any
+on line.  
+The Integrity system would detect the violation and block any
 further reading of such file.
 
 *The update solution must cater with this constrain and must be
@@ -272,8 +287,8 @@ on the entire core OS, generally just before a reboot..*
 
 Connected Cars are comparable to middle volume consumer managed products
 (very similar to connected TV), by this, I mean, product where the
-software is entirely provided by the device manufacturer. The main side
-effects are well known :
+software is entirely provided by the device manufacturer.  
+The main side effects are well known :
 
 -   low cost and small CPU
 -   high control of the OS and Middleware loaded on the box
@@ -284,63 +299,66 @@ effects are well known :
 -   No recovery console.
 
 For those reasons, a solution like Smack has been selected by AGL as the
-best suited LSM front end. Furthermore, its adoption on Tizen by Samsung
+best suited LSM front end.  
+Furthermore, its adoption on Tizen by Samsung
 for delivering millions of Smart TVs enable an active community focussed
 on keeping good performance on smaller CPUs.  
 <https://wiki.tizen.org/wiki/Category:Security>
 
 ## Applications
-*Apps are the weak security vector in many modern system.* Car
-manufacturers need to add bespoke/localised App developers in order to
-make their product commercially attractive. It is a fast moving world
-very different to the use and habits of the Automotive industry.
+*Apps are the weak security vector in many modern system.*  
+Car manufacturers need to add bespoke/localised App developers in order to
+make their product commercially attractive.  
+It is a fast moving world very different to the use and habits of the Automotive industry.
 
-Defining the right level of App vetting is a real challenge. A quick
-reality check on markets where Apps exist, such as Mobile, Smart TV or
+Defining the right level of App vetting is a real challenge.  
+A quick reality check on markets where Apps exist, such as Mobile, Smart TV or
 Smart Watches, show that the detection of roke Apps is very complex
 already on platforms that impose the execution via a Virtual Machine, so
 we can imagine what is the complexity, when native code support is
 required in order to run on very small CPU.
 
-**As we cannot fully trust Apps, we have to contain them**. This can be
-done by :
+**As we cannot fully trust Apps, we have to contain them**.  
+This can be done by :
 
 -   Limiting Apps download origin to trusted ones.
 -   Restrict Apps privileges, resources and APIs access to what is
     explicitly authorised
 -   Isolate Apps runtime
 
-Restricting Apps origin to trusted source is quite simple. The simple
-use of a certificate to validate the App signature is a powerful model
+Restricting Apps origin to trusted source is quite simple.  
+The simple use of a certificate to validate the App signature is a powerful model
 when associated with an installer code which cannot be called via a back
-door. A simple model consists in separating the download process and
+door.  
+A simple model consists in separating the download process and
 exposed (UX, connected) from the installer code which can validate the
 App origin and installation in a isolated process with a lower surface
 of attack.
 
 Restricting Apps privileges requires first to know what are the
-requested and authorised privileges. The granularity of these
-privileges, must offer a good flexibility while remains simple, to be
-understood by the developers and the user. The compromise will depend of
-the target audience. The current return of experience from Android and
-Tizen, tend to reduce the list of privileges to a shorter list rather
-than in opposite. The creation of goup or App class is an other valid
-model.
+requested and authorised privileges.  
+The granularity of these privileges, must offer a good flexibility while remains simple, to be
+understood by the developers and the user.  
+The compromise will depend of the target audience.   
+The current return of experience from Android and Tizen, tend to reduce the list of privileges to a shorter list rather
+than in opposite.  
+The creation of goup or App class is an other valid model.
 
 The list of requested privileges will be associated to the App in a
-Manifest. A practical extra validation of the requested privileges can
+Manifest.  
+A practical extra validation of the requested privileges can
 be done depending of the App origin and signature level (e.g.
 Manufacturer, Partner and Community stores).
 
 The association between the App and its privileges list must be kept
-safe and available for enforcement in the system. The Samsung originated
-Open Source project Cynera (https://github.com/Samsung/cynara) provides
+safe and available for enforcement in the system.  
+The Samsung originated Open Source project Cynera (https://github.com/Samsung/cynara) provides
 such service and is optimised for execution on small SoC.
 
 Isolating the App when running is the most challenging task, it requires
 to let the App access enough of the system to execute its task but no
-more, to mitigate any malicious activity. One model to address this
-challenge consist in slicing the access to the system :
+more, to mitigate any malicious activity.  
+One model to address this challenge consist in slicing the access to the system :
 
 -   CPU, RAM
 -   devices
@@ -362,28 +380,29 @@ isolation via creation of different security context but adds the
 concept of authentication which limit attack through man-in-the-middle
 *https://en.wikipedia.org/wiki/Man-in-the-middle\_attack*.
 
-The control of Libraries and system API usage is far more complex. MAC
-advanced usages can help in this domain but Seccomp-BPF can go further.
+The control of Libraries and system API usage is far more complex.  
+MAC advanced usages can help in this domain but Seccomp-BPF can go further.  
 Seccomp which is an upstream feature of the Linux kernel is used by
 Mozilla and Chrome in their browsers and enable a low level protection
-solution. Seccomp can quickly induce a performance hit and access rules
+solution.  
+Seccomp can quickly induce a performance hit and access rules
 must remain simple.  
 The following page provides interserting reports on performance cost of
 that feature. (https://wiki.tizen.org/wiki/Security:Seccomp) for one
 system.
 
-###Name spaces
+### Name spaces
 
-Containers have made Linux name spaces visible to the mass. They are
-very popular and unfortunately often confused with security enforcement
+Containers have made Linux name spaces visible to the mass.  
+They are very popular and unfortunately often confused with security enforcement
 due to their common use as light virtualisation solution in the cloud.
 
 Whichever model of container is referenced, they all use the Linux
 various name spaces
-(http://man7.org/linux/man-pages/man7/namespaces.7.html). The general
-idea is to share a common kernel and to let each containers run its own
-virtual Linux user space and middleware. With the increased CPU
-performance and the facility provided by novel filesystem architectures
+(http://man7.org/linux/man-pages/man7/namespaces.7.html).  
+The general idea is to share a common kernel and to let each containers run its own
+virtual Linux user space and middleware.  
+With the increased CPU performance and the facility provided by novel filesystem architectures
 such as overlayfs, the files and code which happen to be unchanged
 between different containers can even remain shared transparently on
 disk and in RAM, enabling the use of containers for single App in the
@@ -395,7 +414,7 @@ between themselves, it must remain present to the designer that :
 -   kernel is shared and security weaknesses and zero day defects can be
     used to cross domains.
 -   As each container can provides its own version of the middleware,
-    upgrading the system is not enough to correct known security issues.
+    upgrading the system is not enough to correct known security issues.  
     Each container must individually be updated.
 -   Due to the transparent overlay model sharing files between
     containers, predicting the actually used disk space is challenging.
@@ -409,13 +428,13 @@ Automotive domain :
 -   Easing development
 
 The isolation model is very interesting when multiple service providers
-needs to share the same embedded device. A commonly listed use case, is
-the sharing of an IVI system with games or cloud multimedia services.
+needs to share the same embedded device.  
+A commonly listed use case, is the sharing of an IVI system with games or cloud multimedia services.
 
-The ease of development, is potentially even more valuable. One of the
-challenge faced by the embedded SW industry is the lack of skilled
-embedded software developers. *Enabling web and traditional IT
-programmers to work in a known environment and to run their App on an
+The ease of development, is potentially even more valuable.  
+One of the challenge faced by the embedded SW industry is the lack of skilled
+embedded software developers.  
+*Enabling web and traditional IT programmers to work in a known environment and to run their App on an
 IoT device without requiring to become an embedded SW expert would be of
 a high value*.
 
@@ -439,8 +458,7 @@ few base concepts enforced:
     never work.
 -   SW must be written secured first time, as late adaptation is
     too difficult.
-
-*Underestimating the resistance of the developer team is a common
-mistake which can lead to massive over costs and delays. *Implication of
-the right expert and management drive from the beginning is a
+- Underestimating the resistance of the developer team is a common
+mistake which can lead to massive over costs and delays.
+- Implication of the right expert and management drive from the beginning is a
 requirement that cannot be negotiated.
diff --git a/sec-blueprint/06-plateform-security.md b/sec-blueprint/06-plateform-security.md
index e55dc0b..31fedac 100644
--- a/sec-blueprint/06-plateform-security.md
+++ b/sec-blueprint/06-plateform-security.md
@@ -14,26 +14,28 @@ layout: techdoc
 {:toc}
 
 ## Platform Definition
-The platform includes a set of HW supporting an AGL Linux distribution and AGL compliant Application and Services.
+The platform includes a set of HW supporting an AGL Linux distribution and AGL compliant Application and Services.  
 On the HW side this will include :
- - a SoC
+ - A SoC
  - RAM, ROM and Storage
  - Peripherial
+
 The AGL SW platform includes all the SW required after the initial boot loader in order to support AGL compliant applications and services :
  - Linux BPS configured for the reference boards
  - Set of drivers for the common peripherials available on the reference boards (they may not all be Open Source)
  - Application Framework
  - Windows/layer management to allow Application to gracefully share the displays
  - Sound resource manager to allow Application to gracefully share the displays
- - an atomic update system support / as read only and MAC (Smack)
- - set of building and debug tools (based on yocto project)
+ - An atomic update system support / as read only and MAC (Smack)
+ - Set of building and debug tools (based on yocto project)
 
 ## Secure boot
-The secure boot is tighly linked to the SoC and will vary from SoC to SoC.
+The secure boot is tighly linked to the SoC and will vary from SoC to SoC.  
 AGL does not provide the secure boot but AGL platform is designed to be able to operate with a secure boot.
 
 ## Certificate and Key Management
-The default Key management provided by AGL is SoC independant and use leyrings. Thismodel is less secured than a SoC HW integrated model and we advise AGL adopters to activate HW support from their selected SoC as much as possible.
+The default Key management provided by AGL is SoC independant and use leyrings.  
+This model is less secured than a SoC HW integrated model and we advise AGL adopters to activate HW support from their selected SoC as much as possible.  
 The activation of HW support for Key management if left to the integrator.
 
 ## Madatory Access Control configuration
@@ -49,24 +51,28 @@ Security manager).
 
 https://wiki.tizen.org/wiki/Security/Overview\#Implementation\_in\_Tizen\_3.0\_2015.Q2
 
-*You will notice that the Smack initial configuration described bellow,
+** You will notice that the Smack initial configuration described bellow,
 even if not obvious to read, represents a manageable complexity which
-should be understood in no more than a few hours.***  
-**
+should be understood in no more than a few hours.**
 
 This initial Smack schema tries to clearly keep the differentiation
 between the execution Smack label of a Process and the Smack label of a
-file. The first one defines which file a process can access and how
-files will be created by the process. The second defines which process
-can access the file. By default a process will execute with its file
+file.  
+The first one defines which file a process can access and how
+files will be created by the process.  
+The second defines which process can access the file.  
+By default a process will execute with its file
 access Smack label but that can be overwritten by an execution Smack
 label.
 
 The system is split in 3 domains : 
 
--   **Floor**, which includes the base services and associated data and libraries of the OS which are unchanged during the execution of the OS. Outside of development mode, installation and upgrade software, no one is allowed to write in Floor files and directories.
--   **System**; which includes a reduced set of  core services of the OS and the data that they maintain. Those data are expected to change during the execution of the OS.
--   **Apps, Services and User**, which includes code providing services to the system and user and their associated data. Per concept all code running in this domain are under strict control and isolation by the Cynara and Smacks rules.
+-   **Floor**, which includes the base services and associated data and libraries of the OS which are unchanged during the execution of the OS.  
+Outside of development mode, installation and upgrade software, no one is allowed to write in Floor files and directories.
+-   **System**; which includes a reduced set of  core services of the OS and the data that they maintain.  
+Those data are expected to change during the execution of the OS.
+-   **Apps, Services and User**, which includes code providing services to the system and user and their associated data.  
+Per concept all code running in this domain are under strict control and isolation by the Cynara and Smacks rules.
 
 
 **Floor Domain**
@@ -92,8 +98,8 @@ The system is split in 3 domains :
 |System::Log|Log|rwa for System label<br>xa for user label|None|Some limitation may impose to add w to enable append.|
 |System::Sub|SubSystem|SubSystem Config files|SubSystem only|Isolation of risky SubSystem**|
 
-*\*Runtime:  IoT-OS AppFW always starts a new instance of the runtime for each application (no shared process model is allowed and change the runtime process label to the App Smack label)<br>
-\*\* unconfined mode is reserved for future evolution.*
+* Runtime:  IoT-OS AppFW always starts a new instance of the runtime for each application (no shared process model is allowed and change the runtime process label to the App Smack label)
+* Unconfined mode is reserved for future evolution.
 
 **Apps, services and User Domain**
 -------------------------------------------------------------------------------------------------------------------------
@@ -110,8 +116,8 @@ The system is split in 3 domains :
 ## Resource Management
 
 ## Trust Zone and Trusted Execution
-Trusted zone and Trusted execution are services provided by the SoC vendors and services offered can varie even within the same familly of SoC depending of their configuration.
-AGL platform does not provide any Trusted Zone or Tusted Execution direct support as these are specific to each indivual SoC but on the other side the AGL platform is architectured to ease the use of HW helpers.
+Trusted zone and Trusted execution are services provided by the SoC vendors and services offered can varie even within the same familly of SoC depending of their configuration.  
+AGL platform does not provide any Trusted Zone or Tusted Execution direct support as these are specific to each indivual SoC but on the other side the AGL platform is architectured to ease the use of HW helpers.  
 In particular AGL advise whenever possible to take profit of HW helpers available to store critical data in the secure zone and to execute critical validatin code (in particular signature check) in trusted execution mode.
 
 ## Critical Resource Protection
@@ -122,7 +128,8 @@ AGL platform provides by default a software update module which is capable to re
  - support read only / file system
  - support integrity enforcement such as IMA and EVM.
  - 
-Any update software respecting these requirement can be used. AGL advise strongly to only use solutions that enable a strong verification of the validity and integrity of the download update or upgrade what ever is the selected solution.
+Any update software respecting these requirement can be used.  
+AGL advise strongly to only use solutions that enable a strong verification of the validity and integrity of the download update or upgrade what ever is the selected solution.
 
 ## cloud service infrastructure
 
diff --git a/sec-blueprint/07-application-security.md b/sec-blueprint/07-application-security.md
index 799ce09..09eb3e4 100644
--- a/sec-blueprint/07-application-security.md
+++ b/sec-blueprint/07-application-security.md
@@ -14,17 +14,21 @@ layout: techdoc
 {:toc}
 
 ## Application Definition
-The term of Application (Apps) has a very wide coverage in AGL. To make it short, anything which is not in the core OS, is an App.
+The term of Application (Apps) has a very wide coverage in AGL.  
+To make it short, anything which is not in the core OS, is an App.
 
-Apps can be included in the base image or added after the fact, they can offer a UI, or only offer a service. In AGL, most of the middleware will be treated as Apps.
+Apps can be included in the base image or added after the fact, they can offer a UI, or only offer a service.  
+In AGL, most of the middleware will be treated as Apps.
 
 ## Apps must be installed
-Undependently of the fact that Apps are delivered with the base image or later installed on a running image, Apps are installed under the control of the Application Framework (AppFW). A special off-line mode of the AppFW, allows to install Apps at image creation.\*
+Undependently of the fact that Apps are delivered with the base image or later installed on a running image, Apps are installed under the control of the Application Framework (AppFW).  
+A special off-line mode of the AppFW, allows to install Apps at image creation.\*
 
 **\* Note :** In early release, default Apps are installed on the image at first boot.
 
 ## App containement
-Apps are running in isolation of the system and other Apps. In order to acheive an efficient containement multiple strategies are used :
+Apps are running in isolation of the system and other Apps.  
+In order to acheive an efficient containement multiple strategies are used :
 
 * **Linux Native protection**
   * Smack label (Mandatory Access Control)
@@ -48,7 +52,8 @@ Depending of the implementation, the tracking may be :
 * static, simply enforced at the registration of the App on the repository or dynamic. 
 * dynamic, track and verified at installation by the AppFW.
 
-The origin tracking and validation is critical. It is the first section the chain of trust for providing valid information to the AppFW installer module.
+The origin tracking and validation is critical.  
+It is the first section the chain of trust for providing valid information to the AppFW installer module.
 
 ### Platform security configuration
 
@@ -56,10 +61,14 @@ The AppFW derives from the Meta data received with the App at delivery, which pr
 * Max CPU, RAM, IO, ...
 * Firewall configuration
 * Name spaces ...
-It will create the directories required for the App following the Smack rules described in the "Platform Security" blueprint as well as the associated systemd config files to be used by the launcher.
+It will create the directories required for the App following the Smack rules described in the "Platform Security" blueprint as well as the associated systemd config files to be used by the launcher.  
 As the platform securities services are static for a given release of the OS, the mapping remains simple.
 
-**Important** An App cannot change the CoreOS. It s not allowed for an App to modify or add an element to the CoreOS. Like with containers App are required to embed all the code required for their operation. Within this limitation Apps (which can be a only a service) can still offer services to other App by the mean of AGL binders which use the autenticated AGL transport.
+**Important**  
+* An App cannot change the CoreOS.  
+It s not allowed for an App to modify or add an element to the CoreOS.  
+Like with containers App are required to embed all the code required for their operation.  
+Within this limitation Apps (which can be a only a service) can still offer services to other App by the mean of AGL binders which use the autenticated AGL transport.
 
 ### AGL Platform protections
 
@@ -68,27 +77,30 @@ By default AGL provides three specific protection services :
 * Autenticated transport (via AGL binders, websocket and Oauth2)
 * App origin validation
 
-Because AGL Apps also include services provided by Middleware, new APIs can be created by Apps and new privileges may be required to access those API.
-e.g. a Free Parking space service App from Vinci may offer an API for any Navigation system to read the free parking space count for a given location in order to display it on the Map. We may not want to leave wide open that new API what would induce mobile data with its associated charges.
+Because AGL Apps also include services provided by Middleware, new APIs can be created by Apps and new privileges may be required to access those API.  
+e.g. a Free Parking space service App from Vinci may offer an API for any Navigation system to read the free parking space count for a given location in order to display it on the Map.  
+We may not want to leave wide open that new API what would induce mobile data with its associated charges.
 
-That small use case, shows how AGL AppFW will not only, have to register the privileges requested by an App in Cynara , it will also have to add new privileges associated with API created by Apps.
+That small use case, shows how AGL AppFW will not only, have to register the privileges requested by an App in Cynara, it will also have to add new privileges associated with API created by Apps.
 
 ### Protections enforcement
 
-Platform Securities are enforced by Linux as soon as they are activated. This is the simpler case. We just need to be sure that means to deactivate those protections are removed from the kernel configuration (see Kernel hardning).
+Platform Securities are enforced by Linux as soon as they are activated.  
+This is the simpler case.  
+We just need to be sure that means to deactivate those protections are removed from the kernel configuration (see Kernel hardning).
 
-AGL Platform protections are mostly enforced by dedicated middleware which are protected by the platform securities.
+AGL Platform protections are mostly enforced by dedicated middleware which are protected by the platform securities.  
 Some more risky zones are identified :
 * the creation of binding where an App could create a look a like binding that does not respect any protection.
 * services which provide a wide range of service and need to restict the user request following his profile.
 
-The first one can be enforced by removing by setcomp the option to create websocket directly by an App and requesting the creation to be done via a trusted service at binding enabling.
+The first one can be enforced by removing by setcomp the option to create websocket directly by an App and requesting the creation to be done via a trusted service at binding enabling.  
 The second requires a duplication of some API in order to be able to keep the filtering on the verbs of the API without requiring to drill down to the parameters.
 
 The side effect of this complexity will impose to create an introspection mode where there is the possibility to verify all the API offered by an App and which privileges are required to activate them.
 
 ### Privilege grouping
-In order keep the concept of White listing manageable, a privilege hiercharchy is used.
+In order keep the concept of White listing manageable, a privilege hiercharchy is used.  
 A small example shoudl clarify that concept.
 
    - System:Com:SMS:notify
@@ -111,9 +123,3 @@ A small example shoudl clarify that concept.
    - System:Com:*:notify     (includes SMS:notify & Phone:notify)
 
   That last concept might be too complex to implement and real usefulness should be validated.
-
-
-
-
-
-
diff --git a/sec-blueprint/08-Hardening.md b/sec-blueprint/08-Hardening.md
index 7a6077b..8e2b582 100644
--- a/sec-blueprint/08-Hardening.md
+++ b/sec-blueprint/08-Hardening.md
@@ -14,7 +14,7 @@ Limitations
     at security desktop and server versions of Linux as well as Android
     exploits and hardening.
 
--   Some kernel configuration options can have an impact on performance.
+-   Some kernel configuration options can have an impact on performance.  
     This will be noted where applicable.­
 
 Document Structure
@@ -23,9 +23,10 @@ Document Structure
 This document has been divided into three sections; REQUIREMENTS,
 RECOMMENDATIONS, and VALIDATION. The REQUIREMENTS section details
 explicit requirements that must be adhered to for the embedded
-device**.** The RECOMMENDATIONS section details best practices, and some
-recommended security settings for the embedded device. The third
-section, VALIDATION, provides reference scripts and test procedures that
+device.  
+The RECOMMENDATIONS section details best practices, and some
+recommended security settings for the embedded device.   
+The third section, VALIDATION, provides reference scripts and test procedures that
 can be used to verify adherence with the REQUIREMENTS detailed in the
 first section of this guide.
 
@@ -34,11 +35,11 @@ Hardening
 
 The term *Hardening* refers to the tools, techniques and processes
 required in order to reduce the attack surface on an embedded system,
-such as an embedded control unit (ECU) or other managed device. The
-target for all hardening activities is to prevent the execution of
+such as an embedded control unit (ECU) or other managed device.  
+The target for all hardening activities is to prevent the execution of
 invalid binaries on the device, and to prevent copying of security
-related data from the device. There are three main areas of focus for
-hardening an embedded device:
+related data from the device.  
+There are three main areas of focus for hardening an embedded device:
 
 
 Requirements
@@ -46,7 +47,8 @@ Requirements
 
   For the purposes of reference and explanation, we are providing guidance
   on how to configure an embedded device that runs with a linux 3. 10.17
-  Linux kernel. These requirements must still be met by manufacturers that
+  Linux kernel.  
+  These requirements must still be met by manufacturers that
   opt to build using an alternative version of the Linux kernel.
 
 Kernel Hardening
@@ -55,17 +57,18 @@ Kernel Hardening
   The following sub-sections contain information on various kernel
   configuration options to enhance the security measures in the kernel
   and also for applications compiled to take advantage of these security
-  features. Additionally, there are also configuration options that
-  close known vulnerable configuration options. Here’s a high level
-  summary of various kernel configurations that shall be required for
-  deployment.
+  features.  
+  Additionally, there are also configuration options that
+  close known vulnerable configuration options.  
+  Here’s a high level summary of various kernel configurations that 
+  shall be required for deployment.
 
 ### Disable the serial console
 
   The serial console should be disabled to prevent an attacker from
   accessing this powerful interface.
 
-```
+```bash
   CONFIG_SERIAL_8250=n
   CONFIG_SERIAL_8250_CONSOLE=n
   CONFIG_SERIAL_CORE=n
@@ -75,7 +78,8 @@ Kernel Hardening
 ### Restrict access to kernel memory through device file
 
   The /dev/kmem file in Linux systems is directly mapped to kernel
-  virtual memory. This can be disastrous if an attacker gains root
+  virtual memory.  
+  This can be disastrous if an attacker gains root
   access, as the attacker would have direct access to kernel virtual
   memory.
 
@@ -94,14 +98,14 @@ Kernel Hardening
 
   The kernel command-line is used to control many aspects of the booting
   kernel, and is prone to tampering as they are passed in RAM with
-  little to no reverse validation on these parameters. To prevent this
-  type of attack, the kernel shall be configured to ignore command line
+  little to no reverse validation on these parameters.  
+  To prevent this type of attack, the kernel shall be configured to ignore command line
   arguments, and use pre-configured (compile time) options instead.
 
   Set the kernel command line in the CONFIG\_CMDLINE KConfig item and
   then pass no arguments from the bootloader.
 
-```
+```bash
   CONFIG_CMDLINE_BOOL=y
   CONFIG_CMDLINE=”&lt;*insert kernel command line here*&gt;”
   CONFIG_CMDLINE_OVERRIDE=y
@@ -117,13 +121,14 @@ Kernel Hardening
   Debug symbols should always be removed from production kernels as they
   provide a lot of information to attackers.
 
-```
+```bash
   CONFIG_DEBUG_INFO=n
 ```
 
   These kernel debug symbols are enabled by other config items in the
-  kernel. Care should be taken to disable those also. If
-  CONFIG\_DEBUG\_INFO cannot be disabled then enabling
+  kernel.  
+  Care should be taken to disable those also.  
+  If CONFIG\_DEBUG\_INFO cannot be disabled then enabling
   CONFIG\_DEBUG\_INFO\_REDUCED is second best.
 
 ### Disable access to a kernel core dump
@@ -132,7 +137,7 @@ Kernel Hardening
   user space -- if enabled it gives attackers a useful view into kernel
   memory.
 
-```
+```bash
   CONFIG_PROC_KCORE=n
 ```
 
@@ -140,40 +145,42 @@ Kernel Hardening
 
   The Linux kernel supports KGDB over USB and console ports. These
   mechanisms are controlled by the kgdbdbgp and kgdboc kernel
-  command-line parameters. It is important to ensure that no shipping
+  command-line parameters.  
+  It is important to ensure that no shipping
   product contains a kernel with KGDB compiled-in.
 
-```
+```bash
   CONFIG_KGDB=n
 ```
 
 ### Disable Kprobes
 
   Kprobes enables you to dynamically break into any kernel routine and
-  collect debugging and performance information non-disruptively. You
-  can trap at almost any kernel code address, specifying a handler
+  collect debugging and performance information non-disruptively.  
+  You can trap at almost any kernel code address, specifying a handler
   routine to be invoked when the breakpoint is hit.
 
-```
+```bash
   CONFIG_KPROBES=n
 ```
 
 ### Disable Tracing
 
-  FTrace enables the kernel to trace every kernel function. Providing kernel
-  trace functionality would assist an attacker in discovering attack vectors.
+  FTrace enables the kernel to trace every kernel function.  
+  Providing kernel trace functionality would assist an attacker in discovering attack vectors.
 
-```
+```bash
   CONFIG_FTRACE=n
 ```
 
 ### Disable Profiling
 
   Profiling and OProfile enables profiling the whole system, include the kernel,
-  kernel modules, libraries, and applications.Providing profiling functionality
+  kernel modules, libraries, and applications.  
+  Providing profiling functionality
   would assist an attacker in discovering attack vectors.
 
-```
+```bash
   CONFIG_OPROFILE=n
   CONFIG_PROFILING=n
 ```
@@ -181,12 +188,12 @@ Kernel Hardening
 ### Disable magic sysrq support
 
   On a few architectures, you can access a powerful debugger interface
-  from the keyboard. The same powerful interface can be present on the
-  serial console – responding to serial break – of Linux on other
-  architectures. Disable to avoid potentially exposing this powerful
-  backdoor.
+  from the keyboard.  
+  The same powerful interface can be present on the serial console 
+  – responding to serial break – of Linux on other architectures.  
+  Disable to avoid potentially exposing this powerful backdoor.
 
-```
+```bash
   CONFIG_MAGIC_SYSRQ=n
 ```
 
@@ -196,37 +203,39 @@ Kernel Hardening
   Programming (ROP) when trying to determine the effectives of an
   exploit.
 
-```
+```bash
   CONFIG_DEBUG_BUGVERBOSE=n
 ```
 
 ### Disable kexec
 
-  This prevents someone who gets root from supplanting the kernel. This
-  can be used as a way to bypass signed kernels.
+  This prevents someone who gets root from supplanting the kernel.  
+  This can be used as a way to bypass signed kernels.
 
-```
+```bash
   CONFIG_KEXEC=n
 ```
 
 ### Disable kernel IP autoconfiguration
 
   It is preferable to have IP configuration performed using a user-space
-  tool as these tend to have more validation. We do not want the network
+  tool as these tend to have more validation.  
+  We do not want the network
   interface coming up until the system has come up properly.
 
-```
+```bash
   CONFIG_IP_PNP=n
 ```
 
 ### Disable /proc/config.gz
 
   It is extremely important to not expose the kernel configuration used
-  on a production device to a potential attacker. With access to the
+  on a production device to a potential attacker.  
+  With access to the
   kernel config, it could be possible for an attacker to build a custom
   kernel for the device that may disable critical security features.
 
-```
+```bash
   CONFIG_IKCONFIG=n
 ```
 
@@ -236,17 +245,17 @@ Kernel Hardening
   the memory subsystem and then scour the pages written to swap for
   useful information.
 
-```
+```bash
   CONFIG_SWAP=n
 ```
 
 ### Disable namespace support
 
   Do not allow namespace support to prevent duplicates of dev nodes,
-  pids and mount points. This may be used in virtualization and
-  container solutions like LXC, so in some cases it cannot be disabled.
+  pids and mount points.  
+  This may be used in virtualization and container solutions like LXC, so in some cases it cannot be disabled.
 
-```
+```bash
   CONFIG_NAMESPACES=n
 ```
 
@@ -256,7 +265,7 @@ Kernel Hardening
   builds this can be a very useful way for an attacker to get files onto
   and off of an STB.
 
-```
+```bash
   CONFIG_NFSD=n
   CONFIG_NFS_FS=n
 ```
@@ -264,25 +273,26 @@ Kernel Hardening
 ### Disable support for binary formats other than ELF
 
   This will make possible to plug wrapper-driven binary formats into
-  the kernel. It enables support for binary formats other than ELF. Providing
-  the ability to use alternate interpreters would assist an attacker in
+  the kernel.  
+  It enables support for binary formats other than ELF.  
+  Providing the ability to use alternate interpreters would assist an attacker in
   discovering attack vectors
 
-```
+```bash
   CONFIG_BINFMT_MISC=n
 ```
 
 ### Disable “Load All Symbols”
 
   There is a /proc/kallsyms file which exposes the kernel memory space
-  address of many kernel symbols (functions, variables, etc.). This
-  information is useful to attackers in identifying kernel
+  address of many kernel symbols (functions, variables, etc.).  
+  This information is useful to attackers in identifying kernel
   versions/configurations and in preparing payloads for exploits of
   kernel space.
 
   Both KALLSYMS\_ALL and KALLSYMS shall be disabled;
 
-```
+```bash
   CONFIG_KALLSYMS=n
   CONFIG_KALLSYMS_ALL=n
 ```
@@ -290,17 +300,18 @@ Kernel Hardening
 ### Disable Kernel Debugging
 
   There are development-only branches of code in the kernel enabled by
-  the DEBUG\_KERNEL conf. This should be disabled to compile-out these
-  branches.
+  the DEBUG\_KERNEL conf.  
+  This should be disabled to compile-out these branches.
 
-```
+```bash
   CONFIG_DEBUG_KERNEL=n
 ```
 
   In some kernel versions, disabling this requires also disabling
   CONFIG\_EMBEDDED, and CONFIG\_EXPERT Disabling CONFIG\_EXPERT makes it
   impossible to disable \_COREDUMP, DEBUG\_BUGVERBOSE, \_NAMESPACES,
-  \_KALLSYMS and \_BUG. In which case it is better to leave this enabled
+  \_KALLSYMS and \_BUG.  
+  In which case it is better to leave this enabled
   than enable the others.
 
 ### Disable the kernel debug filesystem
@@ -308,7 +319,7 @@ Kernel Hardening
   The kernel debug filesystem presents a lot of useful information and
   means of manipulation of the kernel to an attacker.
 
-```
+```bash
   CONFIG_DEBUG_FS=n
 ```
 
@@ -318,7 +329,7 @@ Kernel Hardening
   and WARNs in kernel space, making it easier for attackers to develop
   exploits.
 
-```
+```bash
   CONFIG_BUG=n
 ```
 
@@ -327,7 +338,7 @@ Kernel Hardening
   Enabling this will result in code being included that is hard to
   maintain and not well tested.
 
-```
+```bash
   CONFIG_SYSCTL_SYSCALL=n
 ```
 
@@ -335,23 +346,23 @@ Kernel Hardening
 
 ### Disable module unloading
 
-  This stops an attacker unloading security focused kernel modules. It
-  will also prevent the attacker from removing evidence of any attempted
+  This stops an attacker unloading security focused kernel modules.  
+  It will also prevent the attacker from removing evidence of any attempted
   kernel tampering that may have been initiated by loading of a kernel
   module.
 
-```
+```bash
   CONFIG_MODULE_UNLOAD=n
 ```
 
 ### Disable Forced Module Loading
 
   If enabled, then modules without version information or with
-  mismatched version information may be forcibly loaded into the kernel.
+  mismatched version information may be forcibly loaded into the kernel.  
   Disabling this configuration forces the attackers to build modules
   with matched kernel sources and configuration in order to load them.
 
-```
+```bash
   CONFIG_MODULE_FORCE_LOAD=n
 ```
 
@@ -359,7 +370,8 @@ Recommendations
 ===============
 
 The following sections detail best practices that should be applied in
-order to secure a device. Although they are not currently listed as hard
+order to secure a device.  
+Although they are not currently listed as hard
 requirements, they may be upgraded to requirements status in the future.
 
 
@@ -371,10 +383,11 @@ Kernel Hardening
   configuration options that will require updating to a newer kernel
   version in order to enhance the security measures in the kernel and
   also for applications compiled to take advantage of these security
-  features.
+  features.  
 
   Additionally, there are also configuration options that close known
-  vulnerable configuration options. Here’s a high level summary of the
+  vulnerable configuration options.  
+  Here’s a high level summary of the
   various kernel configurations and which kernel version they pertain:
 
 |  Kernel Configuration                 | Kernel Version |
@@ -395,84 +408,91 @@ Kernel Hardening
 ### Build with Stack Protection
 
   Similar to the stack protector used for ELF programs in user-space,
-  the kernel can protect its internal stacks as well. This configuration
-  for the MIPS architecture is supported in Linux 3.11 and greater and
-  thus should only be enabled for such versions. This configuration also
+  the kernel can protect its internal stacks as well.  
+  This configuration for the MIPS architecture is supported in Linux 3.11 and greater and
+  thus should only be enabled for such versions.  
+  This configuration also
   requires building the kernel with the gcc compiler 4.2 or greater.
 
-```
+```bash
   CONFIG_CC_STACKPROTECTOR=y
 ```
 
 ### Disable access to /dev/mem
 
   The /dev/mem file in Linux systems is directly mapped to physical
-  memory. This can be disastrous if an attacker gains root access, as
+  memory.  
+  This can be disastrous if an attacker gains root access, as
   the attacker would have direct access to physical memory through this
-  convenient device file. It may not always be possible to disable such
-  file, as some applications might need such support. In that case then
+  convenient device file.  
+  It may not always be possible to disable such
+  file, as some applications might need such support.  
+  In that case then
   this device file should be available only for authenticated
-  applications. This configuration is supported in Linux 4.0 and greater
+  applications.  
+  This configuration is supported in Linux 4.0 and greater
   and thus should only be disabled for such versions.
 
-```
+```bash
   CONFIG_DEVMEM=n
 ```
 
 ### Disable cross-memory attach
 
   Disable the process\_vm\_\*v syscalls which allow one process to
-  peek/poke the virtual memory of another. This configuration is
+  peek/poke the virtual memory of another.  
+  This configuration is
   supported in Linux 3.5 and greater and thus should only be disabled
   for such versions.
-```
+```bash
   CROSS_MEMORY_ATTACH=n
 ```
 
 ### Disable core dumps
 
-  Core dumps provide lot of debug information for hackers. So disabling
-  core dumps is recommended in production builds. This configuration is
+  Core dumps provide lot of debug information for hackers.  
+  So disabling core dumps is recommended in production builds.  
+  This configuration is
   supported in Linux 3.7 and greater and thus should only be disabled
   for such versions.
 
-```
+```bash
   CONFIG_COREDUMP=n
 ```
 
 ### Disable Legacy Linux Support
 
   There are some Kernel Configs which are present only to support legacy
-  binaries. See also section 2.2.2.18 for disabling support for legacy
-  binary formats. The uselib system call, in particular, has no valid
-  use in any libc6 or uclibc system in recent times. This configuration
-  is supported in Linux 3.15 and greater and thus should only be
+  binaries.  
+  See also section 2.2.2.18 for disabling support for legacy binary formats.  
+  The uselib system call, in particular, has no valid use in any libc6 or uclibc system in recent times.  
+  This configuration is supported in Linux 3.15 and greater and thus should only be
   disabled for such versions.
 
-```
+```bash
   CONFIG_USELIB=n
 ```
 
 ### Disable firmware auto-loading user mode helper
 
   The firmware auto loading helper, which is a utility executed by the
-  kernel on hotplug events requiring firmware, needs to be set setuid.
+  kernel on hotplug events requiring firmware, needs to be set setuid.  
   As a result of this, the helper utility is an attractive target for
-  attackers with control of physical ports on the device. Disabling this
-  configuration is supported in Linux 3.9 and greater.
+  attackers with control of physical ports on the device.  
+  Disabling this configuration is supported in Linux 3.9 and greater.
 
-```
+```bash
   CONFIG_FW_LOADER_USER_HELPER=n
 ```
 
 ### Enable Kernel Panic on OOPS
 
   When fuzzing the kernel or attempting kernel exploits attackers are
-  likely to trigger kernel OOPSes. Setting the behavior on OOPS to PANIC
-  can impede their progress. This configuration is supported in Linux
-  3.5 and greater and thus should only be enabled for such versions.
+  likely to trigger kernel OOPSes.  
+  Setting the behavior on OOPS to PANIC can impede their progress.  
+  This configuration is supported in Linux 3.5 and greater and thus should only be enabled for such versions.
 
-```
+```bash
   CONFIG_PANIC_ON_OOPS=y
 ```
 
@@ -480,13 +500,14 @@ Kernel Hardening
 
   These monitors can be used to inspect shared file descriptors on Unix
   Domain sockets or traffic on ‘localhost’ which is otherwise assumed to
-  be confidential. The **CONFIG\_PACKET\_DIAG** configuration is
-  supported in Linux 3.7 and greater and thus should only be disabled
-  for such versions. The **CONFIG\_UNIX\_DIAG** configuration is
+  be confidential.  
+  The **CONFIG\_PACKET\_DIAG** configuration is supported in Linux 3.7 and greater and thus should only be disabled
+  for such versions.  
+  The **CONFIG\_UNIX\_DIAG** configuration is
   supported in Linux 3.3 and greater and thus should only be disabled
   for such versions.
 
-```
+```bash
   CONFIG_PACKET_DIAG=n
   CONFIG_UNIX_DIAG=n
 ```
@@ -494,21 +515,24 @@ Kernel Hardening
 ### Disable BPF JIT
 
   The BPF JIT can be used to create kernel-payloads from firewall table
-  rules. This configuration for the MIPS architecture is supported in
+  rules.  
+  This configuration for the MIPS architecture is supported in
   Linux 3.16 and greater and thus should only be disabled for such
   versions.
-```
+
+```bash
   BPF_JIT=n
 ```
 
 ### Disable checkpoint/restore
 
   The checkpoint/restore service can take a process, freeze it and
-  migrate it. This results in providing more info than a core dump. This
-  configuration is supported in Linux 3.3 and greater and thus should
+  migrate it.  
+  This results in providing more info than a core dump.  
+  This configuration is supported in Linux 3.3 and greater and thus should
   only be disabled for such versions.
 
-```
+```bash
   CONFIG_CHECKPOINT_RESTORE=n
 ```
 
@@ -517,15 +541,15 @@ Kernel Hardening
   This configuration is supported in Linux 3.7 and greater and thus
   should only be enabled for such versions.
 
-```
+```bash
   CONFIG_MODULE_SIG_FORCE=y
 ```
 
 ### Disable all USB, PCMCIA (and other hotplug bus) drivers that aren’t needed
 
   To reduce the attack surface, the driver enumeration, probe, and
-  operation happen in the kernel. The driver data is parsed by the
-  kernel, so any logic bugs in these drivers can become kernel exploits.
+  operation happen in the kernel.  
+  The driver data is parsed by the kernel, so any logic bugs in these drivers can become kernel exploits.
 
 ### Disable all file systems not needed
 
@@ -536,8 +560,8 @@ Kernel Hardening
 
   When attackers try to develop "run anywhere" exploits for kernel
   vulnerabilities, they frequently need to know the location of internal
-  kernel structures. By treating kernel addresses as sensitive
-  information, those locations are not visible to regular local users.
+  kernel structures.  
+  By treating kernel addresses as sensitive information, those locations are not visible to regular local users.
 
   /proc/sys/kernel/kptr\_restrict is set to "1" to block the reporting
   of known kernel address leaks.
@@ -549,8 +573,8 @@ Kernel Hardening
 ### DMESG Restrictions
 
   When attackers try to develop "run anywhere" exploits for
-  vulnerabilties, they frequently will use dmesg output. By treating
-  dmesg output as sensitive information, this output is not available to
+  vulnerabilties, they frequently will use dmesg output.  
+  By treating dmesg output as sensitive information, this output is not available to
   the attacker.
 
   /proc/sys/kernel/dmesg\_restrict can be set to "1" to treat dmesg
@@ -562,7 +586,7 @@ Kernel Hardening
   options should be enabled to prevent SELlinux from being disabled at
   either runtime or boot time.
 
-```
+```bash
   CONFIG_SECURITY_SELINUX_DEVELOP=n
   CONFIG_SECURITY_SELINUX_DISABLE=n
   CONFIG_SECURITY_SELINUX_BOOTPARAM=n