From d8583d6d7cdba055a69e49801ae70e5c426031ab Mon Sep 17 00:00:00 2001
From: Ronan <ronan.lemartret@iot.bzh>
Date: Mon, 12 Dec 2016 13:22:54 +0100
Subject: fix markdown sec-blueprint
Signed-off-by: Ronan <ronan.lemartret@iot.bzh>
---
sec-blueprint/01-overview.md | 74 ++++-----
sec-blueprint/05-security-concepts.md | 226 ++++++++++++++-------------
sec-blueprint/06-plateform-security.md | 47 +++---
sec-blueprint/07-application-security.md | 46 +++---
sec-blueprint/08-Hardening.md | 254 +++++++++++++++++--------------
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=”<*insert kernel command line here*>”
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
--
cgit