From 5bdfc7472ef18aedac6cf4aca745b797650c1337 Mon Sep 17 00:00:00 2001 From: Dominig ar Foll Date: Thu, 8 Dec 2016 12:11:29 +0100 Subject: reorganisation of file name and order for security blue print Signed-off-by: Dominig ar Foll --- sec-blueprint/02-plateform-security.md | 128 ------- sec-blueprint/02-threat-analysis.md | 48 +++ sec-blueprint/02a-application-security.md | 119 ------ sec-blueprint/03-attack-surfaces.md | 36 ++ sec-blueprint/03-security-concepts.md | 446 ---------------------- sec-blueprint/05-security-concepts.md | 446 ++++++++++++++++++++++ sec-blueprint/05-threat-analysis.md | 48 --- sec-blueprint/06-attack-surfaces.md | 36 -- sec-blueprint/06-plateform-security.md | 128 +++++++ sec-blueprint/07-Hardening.md | 597 ------------------------------ sec-blueprint/07-application-security.md | 119 ++++++ sec-blueprint/08-Hardening.md | 597 ++++++++++++++++++++++++++++++ 12 files changed, 1374 insertions(+), 1374 deletions(-) delete mode 100644 sec-blueprint/02-plateform-security.md create mode 100644 sec-blueprint/02-threat-analysis.md delete mode 100644 sec-blueprint/02a-application-security.md create mode 100644 sec-blueprint/03-attack-surfaces.md delete mode 100644 sec-blueprint/03-security-concepts.md create mode 100644 sec-blueprint/05-security-concepts.md delete mode 100644 sec-blueprint/05-threat-analysis.md delete mode 100644 sec-blueprint/06-attack-surfaces.md create mode 100644 sec-blueprint/06-plateform-security.md delete mode 100644 sec-blueprint/07-Hardening.md create mode 100644 sec-blueprint/07-application-security.md create mode 100644 sec-blueprint/08-Hardening.md (limited to 'sec-blueprint') diff --git a/sec-blueprint/02-plateform-security.md b/sec-blueprint/02-plateform-security.md deleted file mode 100644 index e55dc0b..0000000 --- a/sec-blueprint/02-plateform-security.md +++ /dev/null @@ -1,128 +0,0 @@ ---- - -title : platform Security -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## Platform Definition -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 - - 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) - -## Secure boot -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 activation of HW support for Key management if left to the integrator. - -## Madatory Access Control configuration -The general Smack schema used by AGL is inspired from Tizen 3 Q2/2015 -but tries to enable a better protection of code ran via run time (e.g. -JavaScript, Python) and enable Cloud/Device hybrid applications model. - -It takes into account the Tizen2 experience of creating too complex MAC -rules and limit the use of MAC for process file access tracking leaving -the application capabilities management to other model (Cynara and the -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, -even if not obvious to read, represents a manageable complexity which -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 -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 Domain** - -------------------------------------------------------------------------------------------------------------------------- -|Label| Name | File | Process | Comment | -|:-:|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -| - | Floor | r-x for all | Only kernel and
internal kernel thread
| -- | -| ^ | Hat | --- for all | rx on all domains | only for privileged system Services (today only systemd-journal) useful for backup or virus scan. No file with that label should exist except debug log. | -| * | Star | rwx for all | None | used for device files or /tmp Access restriction managed via DAC. Individual files remain protected by their Smack label. | - - -**System Domain** - -------------------------------------------------------------------------------------------------------------------------- -|Label| Name | File | Process | Comment | -|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -|System|System|none|Privileged
processes|Process should only write on file with transmute attribute.| -|System::run|Run|rwxatl for User and System label|None|files are created with directory label
from user and system domain (transmute)
Lock is implicit with w.| -|System::shared|Shared|rwxatl for system domain
r-x for User label|None|files are created with directory label from system domain (transmute)
User domain has lock privilege| -|System::Log|Log|rwa for System label
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)
-\*\* unconfined mode is reserved for future evolution.* - -**Apps, services and User Domain** -------------------------------------------------------------------------------------------------------------------------- -|Label| Name | File | Process | Comment | -|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -|App::$AppID|AppID|rwx (for files created by the App).
rx for files installed by AppFW|$App runtime
executing $App|One Label per App.
A data Dir is created by the AppFW in rwx.
Older releases still use User::App::$AppID | -|User::Home|Home|rwx-t from System label
r-x-l from App|None|AppFW needs to create Dir in /home/$USER/App-Shared at 1st launch if not present/ with label
app-data access="User::App-Shared"
without transmute.| -|App-Shared|Shared|rwxat from System and User domains label of $User|None|Shared space between all App running for a given user.
Older releases may still use User::App-Shared| - - -## Secured transport for Binder implementation - -## 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. -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 - -## AGL Platform Software Update -AGL platform provides by default a software update module which is capable to respect the AHL platform update requirements: - - support Smack as MAC - - 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. - -## cloud service infrastructure - diff --git a/sec-blueprint/02-threat-analysis.md b/sec-blueprint/02-threat-analysis.md new file mode 100644 index 0000000..c2e4372 --- /dev/null +++ b/sec-blueprint/02-threat-analysis.md @@ -0,0 +1,48 @@ +--- + +title : Treat Analysis & Coverage +date : 2016-06-30 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +## Factory/Dealer installed applications + +## Factory/Dealer installed application updates + +## Factory/Dealer installed application removal + +## User installed applications + +## User installed application update + +## User installed application removal + +## Application Data security + +## Application Data upgrades + +## Vehicle bus write access by Factoy applications + +## Vehicle bus write access by User applications + +## Vehicle bus read access by Factoy applications + +## Vehicle bus read access by User applications + +## Platform software update failure due to corrupted update package + +## Platform software update failure due to corrupted invalid package + +## Attack from the Cloud + +## Man in the middle + +## Malicious CAN / USB devices diff --git a/sec-blueprint/02a-application-security.md b/sec-blueprint/02a-application-security.md deleted file mode 100644 index 799ce09..0000000 --- a/sec-blueprint/02a-application-security.md +++ /dev/null @@ -1,119 +0,0 @@ ---- - -title : Application Security -date : 2016-12-07 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{: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. - -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.\* - -**\* 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 : - -* **Linux Native protection** - * Smack label (Mandatory Access Control) - * Capabilities - * Names Spaces - * Seccomp filter - * Cgroup - * File Integrity -* **AGL Platform protections** - * End2end App author tracking and validation - * Apps Privileges - * Autiticated Apps to Apps/Services transport - - -## Which protection are enforced on an App - -### App origin - -The AGL App development process enforces of the level of autorisation given to an App developper and tracks that autorisation level end2end. -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. - -### Platform security configuration - -The AppFW derives from the Meta data received with the App at delivery, which privileges will be granted to this App : -* 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. -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. - -### AGL Platform protections - -By default AGL provides three specific protection services : -* Privilege management and enforment via cynara -* 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. - -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). - -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 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. -A small example shoudl clarify that concept. - - - System:Com:SMS:notify - - System:Com:SMS:list - - System:Com:SMS:display - - System:Com:SMS:send - - System:Com:SMS:transfer - - System:Com:SMS:* (the * requires to be explicit on global capability request) - - - System:Com:Phone:notify - - System:Com:Phone:list - - System:Com:Phone:display - - System:Com:Phone:send - - System:Com:Phone:transfer - - System:Com:Phone:* - - - System:Com:* (includes SMS:* & Phone:*) - - - - 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/03-attack-surfaces.md b/sec-blueprint/03-attack-surfaces.md new file mode 100644 index 0000000..b82efe1 --- /dev/null +++ b/sec-blueprint/03-attack-surfaces.md @@ -0,0 +1,36 @@ +--- + +title : Attack Surfaces +date : 2016-06-30 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +## OS installation at factory Key leak risk + +## OS boot + +## OS upgrade + +## Device bus (static and autodetection) USB + +## "Wireless connections (Wifi## Bluetooth## ...)" + +## "Wired connection (Can## Serial## Eth ...)" + +## OS-Device file system + +## User data (local & cloud) + +## Application FW + +## Application Store + +## Application data (local & Cloud) diff --git a/sec-blueprint/03-security-concepts.md b/sec-blueprint/03-security-concepts.md deleted file mode 100644 index 114bc8b..0000000 --- a/sec-blueprint/03-security-concepts.md +++ /dev/null @@ -1,446 +0,0 @@ ---- - -title : Application Security Concepts -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## 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 -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 -short time following connection.. - -**So, connected cars security must be designed as a military vehicle -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 - accessibility is easy. -- Known defect should be corrected by SW update in real time, without a return to - home or garage. -- A separation of functionalities in isolated domains should allow the - car to remain safe and operational by limiting the contamination, - would a malicious SW succeed to pass the protections. -- 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. -- 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 - critical resources. - -**The strategy can be summarise as “anything, which is not explicitly -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 -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 -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 -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 -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 -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. -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 -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 -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 -domain. -http://www.grandideastudio.com/wp-content/uploads/secure\_embed\_paper.pdf - -On the SW side, the most efficient model is to work by layer : - -- **be sure that the desired SW is loaded** - On non connected devices, a trusted boot is considered a valid - enough solution, but Connected Cars requirement to enable - applications be added after the initial equipment provisioning, - 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 - 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 - outside world. - Ideally dynamic driver integration after boot should be banned even - if that would limit the flexibility of hot plug for USB devices. - Solutions to reinforce the Linux Kernel integrity during execution, - can be activated but they are an order of magnitude more complex to - activate than keeping bespoke logic in user space. - 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 - privilege (root) we foresee the danger of this traditional - 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) - 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 - the Seccomp can used in addition to LSM to further mitigate - the risks. -- **Isolate Applications** - 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, - 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 - 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 - that such App can claim access, with the enforcement of restriction - in accessing the system resources to those explicitly granted, is a - far more reliable approach. -- **Private data protection** - *Cars know a lot about us, from where we go, to who we call, who get - in our car (via the phone detection) and hold data that we are not - willing to let go in the Open without our explicit consent.* - This creates three main families of requirements : - - - Requires a safe provisioning of new devices and App in the - system (know who is who and who does what. ) - - Enforce encryption to any traffic going out. - - Enforce encryption on local storage for personal data to - mitigate off line attack risk. - - Enforce isolation of devices own by multiple users that connect - to the car. - -## Secure Boot -The trusted or secured boot is a facility offered by most Systems on Chip (SoC) -which enforces : - -- booting the system in a known state - (e.g. all the RAM set to "0", all internal peripherals set - to silent) -- providing a validation that the loaded initial code is signed by a - valid authority - (in short the SW is really coming from a known valid source). - -As the feature is very closed to the HW, almost as many solutions exist -than SoC vendors and many of them requires to buy a large volume of SoC -in order to get access to the facility and are by that requirement not available to generic platform developers. - -The Secured Boot option associated to a modern boot loader such as UEFI or uboot -allows to restrict the execution of the system initialisation code to those which which carries a valid signature. -Even if the system presents some weaknesses and constrains, it is likely -*a valid and accessible solution for most device manufacturers even for -medium volume.* - -Once the trusted boot activated, you will have a good confidence -*(history shows that security loop holes are always available -somewhere)* that the code which will start to run when powering the -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 -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 -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 -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 -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.* -http://sourceforge.net/p/linux-ima/wiki/Home/ - -In short IMA allows the kernel to check that a file has not been changed -by validating it against a stored/calculate hash (called label) while -EVM checks the file attributes (including the extended ones). - -Two types of labels are available : - -- immutable and signed -- 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 -install dynamically and the hash can be recalculated on the fly by the -OS providing a lesser level of protection. - -Obviously some restriction will be imposed on which SW modules are -allowed to update an IMA/EVM label and all public keys used for -signature checking must be protected with an unmutable label or stored -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 -further reading of such file. - -*The update solution must cater with this constrain and must be -implemented via an atomic model where all changes are done in one step, -on the entire core OS, generally just before a reboot..* - -## Mandatory Access Control (MAC) - -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 : - -- low cost and small CPU -- high control of the OS and Middleware loaded on the box -- user, at best, very slow to activate update -- no visibility by the manufacturer of the external environment where - the device is connected. -- No skilled administrator -- 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 -for delivering millions of Smart TVs enable an active community focussed -on keeping good performance on smaller CPUs. - - -## 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. - -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 : - -- 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 -when associated with an installer code which cannot be called via a back -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. - -The list of requested privileges will be associated to the App in a -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 -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 : - -- CPU, RAM -- devices -- network -- middleware -- files -- libraries and system calls. - -CPU and RAM over use can be restricted with a correct C-Group -configuration. - -Devices and files can be isolated by MAC and DAC. - -Network access can be controlled via MAC in association with the -nftables. - -Middleware in AGL is access via binders which provides not only an -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. -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 -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 - -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 -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 -cloud or on small embedded system. - -From a security point of view, while containers provides an isolation -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. - Each container must individually be updated. -- Due to the transparent overlay model sharing files between - containers, predicting the actually used disk space is challenging. -- UX needs to share the same Display and Input what can open back - doors in the system. - -At least two lines of interest seem to provide a serious value for the -Automotive domain : - -- Isolating subsystem -- 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. - -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*. - -The Smack provides a solution to create MAC name spaces, so in theory -nothing would stop to launch containers for each Apps in an isolated -environment. - -As further reading on similar topic, you can have a look at the Open -Source Vasum project. -https://github.com/Samsung/vasum -https://wiki.tizen.org/wiki/Security:Vasum - -## Process Management -While developers will always have a good reason for delaying the -activation of the security layers, to succeed, you will need to keep a -few base concepts enforced: - -- Security is invasive. It goes everywhere. -- Security cannot be apply as a patch at the end of the project. -- System must be developed with the security 'on' or it will - 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 -requirement that cannot be negotiated. diff --git a/sec-blueprint/05-security-concepts.md b/sec-blueprint/05-security-concepts.md new file mode 100644 index 0000000..114bc8b --- /dev/null +++ b/sec-blueprint/05-security-concepts.md @@ -0,0 +1,446 @@ +--- + +title : Application Security Concepts +date : 2016-06-30 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +## 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 +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 +short time following connection.. + +**So, connected cars security must be designed as a military vehicle +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 + accessibility is easy. +- Known defect should be corrected by SW update in real time, without a return to + home or garage. +- A separation of functionalities in isolated domains should allow the + car to remain safe and operational by limiting the contamination, + would a malicious SW succeed to pass the protections. +- 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. +- 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 + critical resources. + +**The strategy can be summarise as “anything, which is not explicitly +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 +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 +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 +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 +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 +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. +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 +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 +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 +domain. +http://www.grandideastudio.com/wp-content/uploads/secure\_embed\_paper.pdf + +On the SW side, the most efficient model is to work by layer : + +- **be sure that the desired SW is loaded** + On non connected devices, a trusted boot is considered a valid + enough solution, but Connected Cars requirement to enable + applications be added after the initial equipment provisioning, + 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 + 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 + outside world. + Ideally dynamic driver integration after boot should be banned even + if that would limit the flexibility of hot plug for USB devices. + Solutions to reinforce the Linux Kernel integrity during execution, + can be activated but they are an order of magnitude more complex to + activate than keeping bespoke logic in user space. + 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 + privilege (root) we foresee the danger of this traditional + 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) + 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 + the Seccomp can used in addition to LSM to further mitigate + the risks. +- **Isolate Applications** + 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, + 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 + 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 + that such App can claim access, with the enforcement of restriction + in accessing the system resources to those explicitly granted, is a + far more reliable approach. +- **Private data protection** + *Cars know a lot about us, from where we go, to who we call, who get + in our car (via the phone detection) and hold data that we are not + willing to let go in the Open without our explicit consent.* + This creates three main families of requirements : + + - Requires a safe provisioning of new devices and App in the + system (know who is who and who does what. ) + - Enforce encryption to any traffic going out. + - Enforce encryption on local storage for personal data to + mitigate off line attack risk. + - Enforce isolation of devices own by multiple users that connect + to the car. + +## Secure Boot +The trusted or secured boot is a facility offered by most Systems on Chip (SoC) +which enforces : + +- booting the system in a known state + (e.g. all the RAM set to "0", all internal peripherals set + to silent) +- providing a validation that the loaded initial code is signed by a + valid authority + (in short the SW is really coming from a known valid source). + +As the feature is very closed to the HW, almost as many solutions exist +than SoC vendors and many of them requires to buy a large volume of SoC +in order to get access to the facility and are by that requirement not available to generic platform developers. + +The Secured Boot option associated to a modern boot loader such as UEFI or uboot +allows to restrict the execution of the system initialisation code to those which which carries a valid signature. +Even if the system presents some weaknesses and constrains, it is likely +*a valid and accessible solution for most device manufacturers even for +medium volume.* + +Once the trusted boot activated, you will have a good confidence +*(history shows that security loop holes are always available +somewhere)* that the code which will start to run when powering the +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 +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 +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 +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 +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.* +http://sourceforge.net/p/linux-ima/wiki/Home/ + +In short IMA allows the kernel to check that a file has not been changed +by validating it against a stored/calculate hash (called label) while +EVM checks the file attributes (including the extended ones). + +Two types of labels are available : + +- immutable and signed +- 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 +install dynamically and the hash can be recalculated on the fly by the +OS providing a lesser level of protection. + +Obviously some restriction will be imposed on which SW modules are +allowed to update an IMA/EVM label and all public keys used for +signature checking must be protected with an unmutable label or stored +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 +further reading of such file. + +*The update solution must cater with this constrain and must be +implemented via an atomic model where all changes are done in one step, +on the entire core OS, generally just before a reboot..* + +## Mandatory Access Control (MAC) + +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 : + +- low cost and small CPU +- high control of the OS and Middleware loaded on the box +- user, at best, very slow to activate update +- no visibility by the manufacturer of the external environment where + the device is connected. +- No skilled administrator +- 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 +for delivering millions of Smart TVs enable an active community focussed +on keeping good performance on smaller CPUs. + + +## 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. + +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 : + +- 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 +when associated with an installer code which cannot be called via a back +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. + +The list of requested privileges will be associated to the App in a +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 +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 : + +- CPU, RAM +- devices +- network +- middleware +- files +- libraries and system calls. + +CPU and RAM over use can be restricted with a correct C-Group +configuration. + +Devices and files can be isolated by MAC and DAC. + +Network access can be controlled via MAC in association with the +nftables. + +Middleware in AGL is access via binders which provides not only an +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. +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 +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 + +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 +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 +cloud or on small embedded system. + +From a security point of view, while containers provides an isolation +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. + Each container must individually be updated. +- Due to the transparent overlay model sharing files between + containers, predicting the actually used disk space is challenging. +- UX needs to share the same Display and Input what can open back + doors in the system. + +At least two lines of interest seem to provide a serious value for the +Automotive domain : + +- Isolating subsystem +- 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. + +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*. + +The Smack provides a solution to create MAC name spaces, so in theory +nothing would stop to launch containers for each Apps in an isolated +environment. + +As further reading on similar topic, you can have a look at the Open +Source Vasum project. +https://github.com/Samsung/vasum +https://wiki.tizen.org/wiki/Security:Vasum + +## Process Management +While developers will always have a good reason for delaying the +activation of the security layers, to succeed, you will need to keep a +few base concepts enforced: + +- Security is invasive. It goes everywhere. +- Security cannot be apply as a patch at the end of the project. +- System must be developed with the security 'on' or it will + 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 +requirement that cannot be negotiated. diff --git a/sec-blueprint/05-threat-analysis.md b/sec-blueprint/05-threat-analysis.md deleted file mode 100644 index c2e4372..0000000 --- a/sec-blueprint/05-threat-analysis.md +++ /dev/null @@ -1,48 +0,0 @@ ---- - -title : Treat Analysis & Coverage -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## Factory/Dealer installed applications - -## Factory/Dealer installed application updates - -## Factory/Dealer installed application removal - -## User installed applications - -## User installed application update - -## User installed application removal - -## Application Data security - -## Application Data upgrades - -## Vehicle bus write access by Factoy applications - -## Vehicle bus write access by User applications - -## Vehicle bus read access by Factoy applications - -## Vehicle bus read access by User applications - -## Platform software update failure due to corrupted update package - -## Platform software update failure due to corrupted invalid package - -## Attack from the Cloud - -## Man in the middle - -## Malicious CAN / USB devices diff --git a/sec-blueprint/06-attack-surfaces.md b/sec-blueprint/06-attack-surfaces.md deleted file mode 100644 index b82efe1..0000000 --- a/sec-blueprint/06-attack-surfaces.md +++ /dev/null @@ -1,36 +0,0 @@ ---- - -title : Attack Surfaces -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## OS installation at factory Key leak risk - -## OS boot - -## OS upgrade - -## Device bus (static and autodetection) USB - -## "Wireless connections (Wifi## Bluetooth## ...)" - -## "Wired connection (Can## Serial## Eth ...)" - -## OS-Device file system - -## User data (local & cloud) - -## Application FW - -## Application Store - -## Application data (local & Cloud) diff --git a/sec-blueprint/06-plateform-security.md b/sec-blueprint/06-plateform-security.md new file mode 100644 index 0000000..e55dc0b --- /dev/null +++ b/sec-blueprint/06-plateform-security.md @@ -0,0 +1,128 @@ +--- + +title : platform Security +date : 2016-06-30 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +## Platform Definition +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 + - 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) + +## Secure boot +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 activation of HW support for Key management if left to the integrator. + +## Madatory Access Control configuration +The general Smack schema used by AGL is inspired from Tizen 3 Q2/2015 +but tries to enable a better protection of code ran via run time (e.g. +JavaScript, Python) and enable Cloud/Device hybrid applications model. + +It takes into account the Tizen2 experience of creating too complex MAC +rules and limit the use of MAC for process file access tracking leaving +the application capabilities management to other model (Cynara and the +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, +even if not obvious to read, represents a manageable complexity which +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 +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 Domain** + +------------------------------------------------------------------------------------------------------------------------- +|Label| Name | File | Process | Comment | +|:-:|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| +| | +| - | Floor | r-x for all | Only kernel and
internal kernel thread
| -- | +| ^ | Hat | --- for all | rx on all domains | only for privileged system Services (today only systemd-journal) useful for backup or virus scan. No file with that label should exist except debug log. | +| * | Star | rwx for all | None | used for device files or /tmp Access restriction managed via DAC. Individual files remain protected by their Smack label. | + + +**System Domain** + +------------------------------------------------------------------------------------------------------------------------- +|Label| Name | File | Process | Comment | +|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| +| | +|System|System|none|Privileged
processes|Process should only write on file with transmute attribute.| +|System::run|Run|rwxatl for User and System label|None|files are created with directory label
from user and system domain (transmute)
Lock is implicit with w.| +|System::shared|Shared|rwxatl for system domain
r-x for User label|None|files are created with directory label from system domain (transmute)
User domain has lock privilege| +|System::Log|Log|rwa for System label
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)
+\*\* unconfined mode is reserved for future evolution.* + +**Apps, services and User Domain** +------------------------------------------------------------------------------------------------------------------------- +|Label| Name | File | Process | Comment | +|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| +| | +|App::$AppID|AppID|rwx (for files created by the App).
rx for files installed by AppFW|$App runtime
executing $App|One Label per App.
A data Dir is created by the AppFW in rwx.
Older releases still use User::App::$AppID | +|User::Home|Home|rwx-t from System label
r-x-l from App|None|AppFW needs to create Dir in /home/$USER/App-Shared at 1st launch if not present/ with label
app-data access="User::App-Shared"
without transmute.| +|App-Shared|Shared|rwxat from System and User domains label of $User|None|Shared space between all App running for a given user.
Older releases may still use User::App-Shared| + + +## Secured transport for Binder implementation + +## 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. +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 + +## AGL Platform Software Update +AGL platform provides by default a software update module which is capable to respect the AHL platform update requirements: + - support Smack as MAC + - 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. + +## cloud service infrastructure + diff --git a/sec-blueprint/07-Hardening.md b/sec-blueprint/07-Hardening.md deleted file mode 100644 index 7a6077b..0000000 --- a/sec-blueprint/07-Hardening.md +++ /dev/null @@ -1,597 +0,0 @@ -Overview -======== - -Scope ------ - -The information contained in this document is applicable to systems based -on Automotive Grade Linux. - -Limitations ------------ - -- This document is based on knowledge and research gained from looking - 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. - This will be noted where applicable.­ - -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 -can be used to verify adherence with the REQUIREMENTS detailed in the -first section of this guide. - -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 -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: - - -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 - opt to build using an alternative version of the Linux kernel. - -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. - -### Disable the serial console - - The serial console should be disabled to prevent an attacker from - accessing this powerful interface. - -``` - CONFIG_SERIAL_8250=n - CONFIG_SERIAL_8250_CONSOLE=n - CONFIG_SERIAL_CORE=n - CONFIG_SERIAL_CORE_CONSOLE=n -``` - -### 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 - access, as the attacker would have direct access to kernel virtual - memory. - - To disable the /dev/kmem file, which is very infrequently used by - applications, the following kernel option should be set in the - compile-time kernel configuration: - -``` - CONFIG_DEVKMEM=n -``` - - In case applications in userspace need /dev/kmem support, it should be - available only for authenticated applications. - -### Bake-in the kernel command-line - - 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 - 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. - -``` - CONFIG_CMDLINE_BOOL=y - CONFIG_CMDLINE=”<*insert kernel command line here*>” - CONFIG_CMDLINE_OVERRIDE=y -``` - - It is recommended that any per-device settings (eg. MAC addresses, - serial numbers, etc.) be stored and accessed from read-only memory (or - files), and that any such parameters be verified (signature checking) - prior to their use. - -### Disable kernel debug symbols - - Debug symbols should always be removed from production kernels as they - provide a lot of information to attackers. - -``` - 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 - CONFIG\_DEBUG\_INFO\_REDUCED is second best. - -### Disable access to a kernel core dump - - This kernel configuration disables access to a kernel core dump from - user space -- if enabled it gives attackers a useful view into kernel - memory. - -``` - CONFIG_PROC_KCORE=n -``` - -### Disable KGDB - - 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 - product contains a kernel with KGDB compiled-in. - -``` - 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 - routine to be invoked when the breakpoint is hit. - -``` - 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. - -``` - CONFIG_FTRACE=n -``` - -### Disable Profiling - - Profiling and OProfile enables profiling the whole system, include the kernel, - kernel modules, libraries, and applications.Providing profiling functionality - would assist an attacker in discovering attack vectors. - -``` - CONFIG_OPROFILE=n - CONFIG_PROFILING=n -``` - -### 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. - -``` - CONFIG_MAGIC_SYSRQ=n -``` - -### Disable OOPS print on BUG() - - The output from OOPS print can be helpful in Return Oriented - Programming (ROP) when trying to determine the effectives of an - exploit. - -``` - 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. - -``` - 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 - interface coming up until the system has come up properly. - -``` - 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 - kernel config, it could be possible for an attacker to build a custom - kernel for the device that may disable critical security features. - -``` - CONFIG_IKCONFIG=n -``` - -### Disable swap - - If not disabled, attackers can enable swap at runtime, add pressure to - the memory subsystem and then scour the pages written to swap for - useful information. - -``` - 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. - -``` - CONFIG_NAMESPACES=n -``` - -### Disable NFS file system - - While often enabled in development, when left enabled in production - builds this can be a very useful way for an attacker to get files onto - and off of an STB. - -``` - CONFIG_NFSD=n - CONFIG_NFS_FS=n -``` - -### 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 - discovering attack vectors - -``` - 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 - versions/configurations and in preparing payloads for exploits of - kernel space. - - Both KALLSYMS\_ALL and KALLSYMS shall be disabled; - -``` - CONFIG_KALLSYMS=n - CONFIG_KALLSYMS_ALL=n -``` - -### 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. - -``` - 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 - than enable the others. - -### Disable the kernel debug filesystem - - The kernel debug filesystem presents a lot of useful information and - means of manipulation of the kernel to an attacker. - -``` - CONFIG_DEBUG_FS=n -``` - -### Disable BUG() support - - The kernel will display backtrace and register information for BUGs - and WARNs in kernel space, making it easier for attackers to develop - exploits. - -``` - CONFIG_BUG=n -``` - -### Disable Sysctl syscall support - - Enabling this will result in code being included that is hard to - maintain and not well tested. - -``` - CONFIG_SYSCTL_SYSCALL=n -``` - -### Kernel Modules - -### Disable module unloading - - 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. - -``` - 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. - Disabling this configuration forces the attackers to build modules - with matched kernel sources and configuration in order to load them. - -``` - CONFIG_MODULE_FORCE_LOAD=n -``` - -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 -requirements, they may be upgraded to requirements status in the future. - - - -Kernel Hardening ----------------- - - The following sub-sections contain information on various kernel - 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. - - Additionally, there are also configuration options that close known - vulnerable configuration options. Here’s a high level summary of the - various kernel configurations and which kernel version they pertain: - -| Kernel Configuration | Kernel Version | -|---------------------------------------|----------------| -| CONFIG\_CHECKPOINT\_RESTORE=n |3.3+ | -| CONFIG\_UNIX\_DIAG=n |3.3+ | -| CROSS\_MEMORY\_ATTACH=n |3.5+ | -| CONFIG\_PANIC\_ON\_OOPS=y |3.5+ | -| CONFIG\_COREDUMP=n |3.7+ | -| CONFIG\_MODULE\_SIG\_FORCE=y |3.7+ | -| CONFIG\_PACKET\_DIAG=n |3.7+ | -| CONFIG\_FW\_LOADER\_USER\_HELPER=n |3.9+ | -| CONFIG\_CC\_STACKPROTECTOR=y |3.11+ (MIPS) | -| CONFIG\_USELIB=n |3.15+ | -| BPF\_JIT=n |3.16+ (MIPS) | -| CONFIG\_DEVMEM=n |4.0+ | - -### 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 - requires building the kernel with the gcc compiler 4.2 or greater. - -``` - 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 - 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 - this device file should be available only for authenticated - applications. This configuration is supported in Linux 4.0 and greater - and thus should only be disabled for such versions. - -``` - 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 - supported in Linux 3.5 and greater and thus should only be disabled - for such versions. -``` - 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 - supported in Linux 3.7 and greater and thus should only be disabled - for such versions. - -``` - 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 - disabled for such versions. - -``` - 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. - 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. - -``` - 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. - -``` - CONFIG_PANIC_ON_OOPS=y -``` - -### Disable socket monitoring interface - - 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 - supported in Linux 3.3 and greater and thus should only be disabled - for such versions. - -``` - CONFIG_PACKET_DIAG=n - CONFIG_UNIX_DIAG=n -``` - -### 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 - Linux 3.16 and greater and thus should only be disabled for such - versions. -``` - 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 - only be disabled for such versions. - -``` - CONFIG_CHECKPOINT_RESTORE=n -``` - -### Enable Enforced Module Signing - - This configuration is supported in Linux 3.7 and greater and thus - should only be enabled for such versions. - -``` - 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. - -### Disable all file systems not needed - - To reduce the attack surface; file system data is parsed by the kernel - so any logic bugs in file system drivers can become kernel exploits. - -### Kernel Address Display Restriction - - 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. - - /proc/sys/kernel/kptr\_restrict is set to "1" to block the reporting - of known kernel address leaks. - - Additionally, various files and directories should be readable only by - the root user: /boot/vmlinuz\*, /boot/System.map\*, - /sys/kernel/debug/, /proc/slabinfo - -### 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 - the attacker. - - /proc/sys/kernel/dmesg\_restrict can be set to "1" to treat dmesg - output as sensitive. - -### SELinux - - If SELinux is in use on the embedded system, the following kernel - options should be enabled to prevent SELlinux from being disabled at - either runtime or boot time. - -``` - CONFIG_SECURITY_SELINUX_DEVELOP=n - CONFIG_SECURITY_SELINUX_DISABLE=n - CONFIG_SECURITY_SELINUX_BOOTPARAM=n -``` - - -Validation -========== - -Image Security Analysis Framework (ISAFW) ------------------------------------------ -**meta-security-isafw** is an OE layer that allows enabling the Image -Security Analysis Framework (isafw) for your image builds. - -The primary purpose of isafw is to provide an extensible -framework for analysing different security aspects of images -during the build process. - -The isafw project itself can be found at - https://github.com/01org/isafw - -This layer can be added to your builds to produce an analysis report, -including a kernel config analysis. - -### Usage - -In order to enable the isafw during the image build, please add -the following line to your build/conf/local.conf file: - -```python -INHERIT += "isafw" -``` diff --git a/sec-blueprint/07-application-security.md b/sec-blueprint/07-application-security.md new file mode 100644 index 0000000..799ce09 --- /dev/null +++ b/sec-blueprint/07-application-security.md @@ -0,0 +1,119 @@ +--- + +title : Application Security +date : 2016-12-07 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{: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. + +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.\* + +**\* 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 : + +* **Linux Native protection** + * Smack label (Mandatory Access Control) + * Capabilities + * Names Spaces + * Seccomp filter + * Cgroup + * File Integrity +* **AGL Platform protections** + * End2end App author tracking and validation + * Apps Privileges + * Autiticated Apps to Apps/Services transport + + +## Which protection are enforced on an App + +### App origin + +The AGL App development process enforces of the level of autorisation given to an App developper and tracks that autorisation level end2end. +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. + +### Platform security configuration + +The AppFW derives from the Meta data received with the App at delivery, which privileges will be granted to this App : +* 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. +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. + +### AGL Platform protections + +By default AGL provides three specific protection services : +* Privilege management and enforment via cynara +* 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. + +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). + +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 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. +A small example shoudl clarify that concept. + + - System:Com:SMS:notify + - System:Com:SMS:list + - System:Com:SMS:display + - System:Com:SMS:send + - System:Com:SMS:transfer + - System:Com:SMS:* (the * requires to be explicit on global capability request) + + - System:Com:Phone:notify + - System:Com:Phone:list + - System:Com:Phone:display + - System:Com:Phone:send + - System:Com:Phone:transfer + - System:Com:Phone:* + + - System:Com:* (includes SMS:* & Phone:*) + + + - 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 new file mode 100644 index 0000000..7a6077b --- /dev/null +++ b/sec-blueprint/08-Hardening.md @@ -0,0 +1,597 @@ +Overview +======== + +Scope +----- + +The information contained in this document is applicable to systems based +on Automotive Grade Linux. + +Limitations +----------- + +- This document is based on knowledge and research gained from looking + 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. + This will be noted where applicable.­ + +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 +can be used to verify adherence with the REQUIREMENTS detailed in the +first section of this guide. + +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 +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: + + +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 + opt to build using an alternative version of the Linux kernel. + +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. + +### Disable the serial console + + The serial console should be disabled to prevent an attacker from + accessing this powerful interface. + +``` + CONFIG_SERIAL_8250=n + CONFIG_SERIAL_8250_CONSOLE=n + CONFIG_SERIAL_CORE=n + CONFIG_SERIAL_CORE_CONSOLE=n +``` + +### 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 + access, as the attacker would have direct access to kernel virtual + memory. + + To disable the /dev/kmem file, which is very infrequently used by + applications, the following kernel option should be set in the + compile-time kernel configuration: + +``` + CONFIG_DEVKMEM=n +``` + + In case applications in userspace need /dev/kmem support, it should be + available only for authenticated applications. + +### Bake-in the kernel command-line + + 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 + 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. + +``` + CONFIG_CMDLINE_BOOL=y + CONFIG_CMDLINE=”<*insert kernel command line here*>” + CONFIG_CMDLINE_OVERRIDE=y +``` + + It is recommended that any per-device settings (eg. MAC addresses, + serial numbers, etc.) be stored and accessed from read-only memory (or + files), and that any such parameters be verified (signature checking) + prior to their use. + +### Disable kernel debug symbols + + Debug symbols should always be removed from production kernels as they + provide a lot of information to attackers. + +``` + 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 + CONFIG\_DEBUG\_INFO\_REDUCED is second best. + +### Disable access to a kernel core dump + + This kernel configuration disables access to a kernel core dump from + user space -- if enabled it gives attackers a useful view into kernel + memory. + +``` + CONFIG_PROC_KCORE=n +``` + +### Disable KGDB + + 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 + product contains a kernel with KGDB compiled-in. + +``` + 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 + routine to be invoked when the breakpoint is hit. + +``` + 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. + +``` + CONFIG_FTRACE=n +``` + +### Disable Profiling + + Profiling and OProfile enables profiling the whole system, include the kernel, + kernel modules, libraries, and applications.Providing profiling functionality + would assist an attacker in discovering attack vectors. + +``` + CONFIG_OPROFILE=n + CONFIG_PROFILING=n +``` + +### 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. + +``` + CONFIG_MAGIC_SYSRQ=n +``` + +### Disable OOPS print on BUG() + + The output from OOPS print can be helpful in Return Oriented + Programming (ROP) when trying to determine the effectives of an + exploit. + +``` + 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. + +``` + 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 + interface coming up until the system has come up properly. + +``` + 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 + kernel config, it could be possible for an attacker to build a custom + kernel for the device that may disable critical security features. + +``` + CONFIG_IKCONFIG=n +``` + +### Disable swap + + If not disabled, attackers can enable swap at runtime, add pressure to + the memory subsystem and then scour the pages written to swap for + useful information. + +``` + 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. + +``` + CONFIG_NAMESPACES=n +``` + +### Disable NFS file system + + While often enabled in development, when left enabled in production + builds this can be a very useful way for an attacker to get files onto + and off of an STB. + +``` + CONFIG_NFSD=n + CONFIG_NFS_FS=n +``` + +### 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 + discovering attack vectors + +``` + 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 + versions/configurations and in preparing payloads for exploits of + kernel space. + + Both KALLSYMS\_ALL and KALLSYMS shall be disabled; + +``` + CONFIG_KALLSYMS=n + CONFIG_KALLSYMS_ALL=n +``` + +### 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. + +``` + 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 + than enable the others. + +### Disable the kernel debug filesystem + + The kernel debug filesystem presents a lot of useful information and + means of manipulation of the kernel to an attacker. + +``` + CONFIG_DEBUG_FS=n +``` + +### Disable BUG() support + + The kernel will display backtrace and register information for BUGs + and WARNs in kernel space, making it easier for attackers to develop + exploits. + +``` + CONFIG_BUG=n +``` + +### Disable Sysctl syscall support + + Enabling this will result in code being included that is hard to + maintain and not well tested. + +``` + CONFIG_SYSCTL_SYSCALL=n +``` + +### Kernel Modules + +### Disable module unloading + + 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. + +``` + 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. + Disabling this configuration forces the attackers to build modules + with matched kernel sources and configuration in order to load them. + +``` + CONFIG_MODULE_FORCE_LOAD=n +``` + +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 +requirements, they may be upgraded to requirements status in the future. + + + +Kernel Hardening +---------------- + + The following sub-sections contain information on various kernel + 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. + + Additionally, there are also configuration options that close known + vulnerable configuration options. Here’s a high level summary of the + various kernel configurations and which kernel version they pertain: + +| Kernel Configuration | Kernel Version | +|---------------------------------------|----------------| +| CONFIG\_CHECKPOINT\_RESTORE=n |3.3+ | +| CONFIG\_UNIX\_DIAG=n |3.3+ | +| CROSS\_MEMORY\_ATTACH=n |3.5+ | +| CONFIG\_PANIC\_ON\_OOPS=y |3.5+ | +| CONFIG\_COREDUMP=n |3.7+ | +| CONFIG\_MODULE\_SIG\_FORCE=y |3.7+ | +| CONFIG\_PACKET\_DIAG=n |3.7+ | +| CONFIG\_FW\_LOADER\_USER\_HELPER=n |3.9+ | +| CONFIG\_CC\_STACKPROTECTOR=y |3.11+ (MIPS) | +| CONFIG\_USELIB=n |3.15+ | +| BPF\_JIT=n |3.16+ (MIPS) | +| CONFIG\_DEVMEM=n |4.0+ | + +### 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 + requires building the kernel with the gcc compiler 4.2 or greater. + +``` + 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 + 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 + this device file should be available only for authenticated + applications. This configuration is supported in Linux 4.0 and greater + and thus should only be disabled for such versions. + +``` + 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 + supported in Linux 3.5 and greater and thus should only be disabled + for such versions. +``` + 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 + supported in Linux 3.7 and greater and thus should only be disabled + for such versions. + +``` + 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 + disabled for such versions. + +``` + 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. + 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. + +``` + 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. + +``` + CONFIG_PANIC_ON_OOPS=y +``` + +### Disable socket monitoring interface + + 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 + supported in Linux 3.3 and greater and thus should only be disabled + for such versions. + +``` + CONFIG_PACKET_DIAG=n + CONFIG_UNIX_DIAG=n +``` + +### 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 + Linux 3.16 and greater and thus should only be disabled for such + versions. +``` + 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 + only be disabled for such versions. + +``` + CONFIG_CHECKPOINT_RESTORE=n +``` + +### Enable Enforced Module Signing + + This configuration is supported in Linux 3.7 and greater and thus + should only be enabled for such versions. + +``` + 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. + +### Disable all file systems not needed + + To reduce the attack surface; file system data is parsed by the kernel + so any logic bugs in file system drivers can become kernel exploits. + +### Kernel Address Display Restriction + + 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. + + /proc/sys/kernel/kptr\_restrict is set to "1" to block the reporting + of known kernel address leaks. + + Additionally, various files and directories should be readable only by + the root user: /boot/vmlinuz\*, /boot/System.map\*, + /sys/kernel/debug/, /proc/slabinfo + +### 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 + the attacker. + + /proc/sys/kernel/dmesg\_restrict can be set to "1" to treat dmesg + output as sensitive. + +### SELinux + + If SELinux is in use on the embedded system, the following kernel + options should be enabled to prevent SELlinux from being disabled at + either runtime or boot time. + +``` + CONFIG_SECURITY_SELINUX_DEVELOP=n + CONFIG_SECURITY_SELINUX_DISABLE=n + CONFIG_SECURITY_SELINUX_BOOTPARAM=n +``` + + +Validation +========== + +Image Security Analysis Framework (ISAFW) +----------------------------------------- +**meta-security-isafw** is an OE layer that allows enabling the Image +Security Analysis Framework (isafw) for your image builds. + +The primary purpose of isafw is to provide an extensible +framework for analysing different security aspects of images +during the build process. + +The isafw project itself can be found at + https://github.com/01org/isafw + +This layer can be added to your builds to produce an analysis report, +including a kernel config analysis. + +### Usage + +In order to enable the isafw during the image build, please add +the following line to your build/conf/local.conf file: + +```python +INHERIT += "isafw" +``` -- cgit