diff options
Diffstat (limited to 'sec-blueprint')
| -rw-r--r-- | sec-blueprint/01-overview.md | 41 | ||||
| -rw-r--r-- | sec-blueprint/04-adversaries.md | 19 | ||||
| -rw-r--r-- | sec-blueprint/05-security-concepts.md | 165 | ||||
| -rw-r--r-- | sec-blueprint/06-plateform-security.md | 86 | ||||
| -rw-r--r-- | sec-blueprint/07-application-security.md | 50 | ||||
| -rw-r--r-- | sec-blueprint/08-Hardening.md | 295 | ||||
| -rw-r--r-- | sec-blueprint/index.md | 1 |
7 files changed, 331 insertions, 326 deletions
diff --git a/sec-blueprint/01-overview.md b/sec-blueprint/01-overview.md index ae3c23c..7b26ba1 100644 --- a/sec-blueprint/01-overview.md +++ b/sec-blueprint/01-overview.md @@ -11,9 +11,11 @@ layout: techdoc **Table of Content** 1. TOC + {:toc} ## Introduction + ### Abstract This document describes how it is possible to create reasonably secured connected cars using already available Open Source components. @@ -32,7 +34,7 @@ Proven solutions derived from the IT world are for most of them, inapplicable. For many people the Cyber Security risk for the Automotive industry is still at best not understood and unfortunately more often, simply ignored. If the Fiat-Chrysler cyber car jacking has forced the industry to open their eyes, it is just a beginning. -- 24 Jul 2015 Hacking a radio in a car: +- 24 Jul 2015 Hacking a radio in a car: *"… the computer systems built into Fiat Chrysler cars: the flaw can be exploited by an attacker to wirelessly take control of the engine, brakes and entertainment system ..." @@ -40,7 +42,7 @@ If the Fiat-Chrysler cyber car jacking has forced the industry to open their eye recalled 1.4 million of the manufacturer's cars after a dangerous software flaw was revealed just days ago..."* <http://www.theregister.co.uk/2015/07/24/chrysler_recall_for_wireless_hacking_hole/> -- One day (likely not that far) we could see car blocked by +- One day (likely not that far) we could see car blocked by ramsomware, or cyber terrorism using cars as weapon if nothing is done. @@ -55,7 +57,8 @@ that tracking a mobile source will be more complex. <http://www.theregister.co.uk/2016/10/10/iot\_botnet/> -## Scope +## Scope + Designing Connected cars without enabling a high level of security is not acceptable and will be soon a key market requirement for any respectable automotive company. @@ -68,19 +71,19 @@ Connected Car. The assumptions selected are the following: -- Secure boot with Hardware chain of trust. -- recent LTSI based kernel (4.1.x, 4.9.x, ...) -- kernel and middleware securely updated once in a while - in the future that rate will increase a lot. -- Middleware and Application compiled with up-to-date compiler - protections activated and checked through a static analysis process. -- Rootfs (/) in read-only, /home encrypted., integrity protected by - IMA/EVM -- Customisation reduced to Apps vetted by the manufacturer's store -- 24/7 connection to the outside world (sensor and internet). -- Developer mode not active by default. -- There is no administrator (only a user) for the product which mostly - run non attended. +- Secure boot with Hardware chain of trust. +- recent LTSI based kernel (4.1.x, 4.9.x, ...) +- kernel and middleware securely updated once in a while + in the future that rate will increase a lot. +- Middleware and Application compiled with up-to-date compiler + protections activated and checked through a static analysis process. +- Rootfs (/) in read-only, /home encrypted., integrity protected by + IMA/EVM +- Customisation reduced to Apps vetted by the manufacturer's store +- 24/7 connection to the outside world (sensor and internet). +- Developer mode not active by default. +- There is no administrator (only a user) for the product which mostly + run non attended. We can see that in such configuration, the base OS (kernel&middleware) represents a well guarded entry point for a malicious hacker. @@ -130,12 +133,8 @@ Those types of code are normally called from a very limited entry points in the system and once again the MAC system is your best friend when it comes to restrict activation from valid vector. - ## Glossary DAC Discretionaly Access Control MAC Mandatory Access Control -SoC System on Chip - - - +SoC System on Chip
\ No newline at end of file diff --git a/sec-blueprint/04-adversaries.md b/sec-blueprint/04-adversaries.md index 8740ae5..1dd4758 100644 --- a/sec-blueprint/04-adversaries.md +++ b/sec-blueprint/04-adversaries.md @@ -1,5 +1,7 @@ This section lists some of the adversaries and attackers in Automotive. -## Enthusiast Attackers: + +## Enthusiast Attackers + Enthusiast attackers have physical access to the Engine Control Units (ECUs) at the circuit board level. They can solder ‘mod chips’ onto the board and have access to probing tools. They also have @@ -9,14 +11,16 @@ This section lists some of the adversaries and attackers in Automotive. could be, but is not limited to, adding extra horse power to the car or hacking it just for fun. -## Corrupt Dealers: +## Corrupt Dealers + These are attackers that have access to the same capabilities as enthusiasts, but also have access to the car manufacturer's (OEM) dealer network. They may also have access to standard debugging tools provided by the car manufacturer. Their goal may be to support local car theft gangs or organized criminals. -## Organized Criminal: +## Organized Criminal + Organized Criminals have access to all of the above tools but may also have some level of control over the internal network at many dealerships. They may have hacked and gained temporary @@ -26,7 +30,8 @@ This section lists some of the adversaries and attackers in Automotive. Their goal is to extort money from an OEMs and/or governments by threatening to disable multiple vehicles. -## Malware Developers: +## Malware Developers + Malware Developers have developed malicious software to attach and compromise a large number of vehicle. The malicious software would usually be designed spread from one vehicle to another. @@ -34,11 +39,11 @@ This section lists some of the adversaries and attackers in Automotive. access to them for malicious purposes like denial-of-service (DoS) attacks or stealing private information and data. -## Security Researchers: +## Security Researchers + These attackers are ‘self-publicized’ security consultants trying to make a name for themselves. They have access standard tools for software security analysis. They also have physical access to the vehicle and standard hardware debugging tools (Logic Analyzers, Oscilloscopes, etc). Their goal is to publicize attacks for personal - gains. - + gains.
\ No newline at end of file diff --git a/sec-blueprint/05-security-concepts.md b/sec-blueprint/05-security-concepts.md index 5ddfe5b..48eb572 100644 --- a/sec-blueprint/05-security-concepts.md +++ b/sec-blueprint/05-security-concepts.md @@ -11,9 +11,11 @@ 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. @@ -33,23 +35,23 @@ short time following connection.. 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 +- 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 +- 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 +- 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 +- 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 +- 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 +- 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 +- 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 @@ -91,6 +93,7 @@ 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, @@ -108,18 +111,18 @@ 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 +<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** +- **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 +- **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 @@ -127,7 +130,7 @@ On the SW side, the most efficient model is to work by layer : *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.** +- **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 @@ -141,8 +144,8 @@ On the SW side, the most efficient model is to work by layer : 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.** + <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 @@ -152,7 +155,7 @@ On the SW side, the most efficient model is to work by layer : 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) + <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 @@ -163,7 +166,7 @@ On the SW side, the most efficient model is to work by layer : 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** +- **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 @@ -183,30 +186,28 @@ On the SW side, the most efficient model is to work by layer : 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. +- **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). +- 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 @@ -223,7 +224,7 @@ Once the trusted boot activated, you will have a good confidence somewhere)* that the code which will start to run when powering the device, is the expected one. -## Read Only root file system. +## Read Only root file system In most embedded system the core OS is under control of the device manufacturer. @@ -239,7 +240,7 @@ 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 +<https://github.com/torvalds/linux/commit/e9be9d5e76e34872f0c37d72e25bc27fe9e2c54c> ## Code Integrity during execution @@ -249,7 +250,7 @@ We can take profit of this favorable position, to limit the capabilities of a ma 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/ +<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 @@ -257,8 +258,8 @@ EVM checks the file attributes (including the extended ones). Two types of labels are available : -- immutable and signed -- simple +- immutable and signed +- simple The signed labels are reserved for code or data which are static and provide the best level of protection. @@ -290,13 +291,13 @@ Connected Cars are comparable to middle volume consumer managed products 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. +- 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. @@ -306,6 +307,7 @@ on keeping good performance on smaller CPUs. <https://wiki.tizen.org/wiki/Category:Security> ## Applications + *Apps are the weak security vector in many modern system.* Car manufacturers need to add bespoke/localised App developers in order to make their product commercially attractive. @@ -321,10 +323,10 @@ 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 +- 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 @@ -352,7 +354,7 @@ 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 +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 @@ -360,12 +362,12 @@ 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, RAM +- devices +- network +- middleware +- files +- libraries and system calls. CPU and RAM over use can be restricted with a correct C-Group configuration. @@ -378,7 +380,7 @@ 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*. +*<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. @@ -388,7 +390,7 @@ 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 +that feature. (<https://wiki.tizen.org/wiki/Security:Seccomp>) for one system. ### Name spaces @@ -399,7 +401,7 @@ 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). +(<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 @@ -411,21 +413,21 @@ 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. +- 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 +- Isolating subsystem +- Easing development The isolation model is very interesting when multiple service providers needs to share the same embedded device. @@ -444,21 +446,22 @@ 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 +<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. +- 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. + 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. + requirement that cannot be negotiated. diff --git a/sec-blueprint/06-plateform-security.md b/sec-blueprint/06-plateform-security.md index 3940672..41de4f0 100644 --- a/sec-blueprint/06-plateform-security.md +++ b/sec-blueprint/06-plateform-security.md @@ -11,34 +11,41 @@ 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 + +- 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) + +- 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. This model is less secured than a SoC HW integrated model and we advise AGL adopters to activate HW support from their selected SoC as much as possible. The activation of HW support for Key management if left to the integrator. ## Madatory Access Control configuration + 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. @@ -48,8 +55,7 @@ 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 +<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 @@ -67,58 +73,57 @@ label. The system is split in 3 domains : -- **Floor**, which includes the base services and associated data and libraries of the OS which are unchanged during the execution of the OS. -Outside of development mode, installation and upgrade software, no one is allowed to write in Floor files and directories. -- **System**; which includes a reduced set of core services of the OS and the data that they maintain. -Those data are expected to change during the execution of the OS. -- **Apps, Services and User**, which includes code providing services to the system and user and their associated data. -Per concept all code running in this domain are under strict control and isolation by the Cynara and Smacks rules. - +- **Floor**, which includes the base services and associated data and libraries of the OS which are unchanged during the execution of the OS. + Outside of development mode, installation and upgrade software, no one is allowed to write in Floor files and directories. +- **System**; which includes a reduced set of core services of the OS and the data that they maintain. + Those data are expected to change during the execution of the OS. +- **Apps, Services and User**, which includes code providing services to the system and user and their associated data. + Per concept all code running in this domain are under strict control and isolation by the Cynara and Smacks rules. -**Floor Domain** +## Floor Domain ------------------------------------------------------------------------------------------------------------------------- |Label| Name | File | Process | Comment | |:-:|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| | | -| - | Floor | r-x for all | Only kernel and<br>internal kernel thread <br>| -- | +| - | 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** +## System Domain ------------------------------------------------------------------------------------------------------------------------- |Label| Name | File | Process | Comment | |:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| | | -|System|System|none|Privileged<br>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<br>from user and system domain (transmute)<br>Lock is implicit with w.| -|System::shared|Shared|rwxatl for system domain<br>r-x for User label|None|files are created with directory label from system domain (transmute)<br>User domain has lock privilege| -|System::Log|Log|rwa for System label<br>xa for user label|None|Some limitation may impose to add w to enable append.| +|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. +- 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 -**Apps, services and User Domain** ------------------------------------------------------------------------------------------------------------------------- |Label| Name | File | Process | Comment | |:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| | | -|App::$AppID|AppID|rwx (for files created by the App).<br>rx for files installed by AppFW|$App runtime<br>executing $App|One Label per App.<br>A data Dir is created by the AppFW in rwx.<br>Older releases still use User::App::$AppID | -|User::Home|Home|rwx-t from System label<br>r-x-l from App|None|AppFW needs to create Dir in /home/$USER/App-Shared at 1st launch if not present/ with label<br>app-data access="User::App-Shared"<br>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.<br>Older releases may still use User::App-Shared| - +|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. @@ -126,13 +131,14 @@ In particular AGL advise whenever possible to take profit of HW helpers availabl ## 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. - - + +- 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 - +## cloud service infrastructure
\ No newline at end of file diff --git a/sec-blueprint/07-application-security.md b/sec-blueprint/07-application-security.md index 09eb3e4..2c757b0 100644 --- a/sec-blueprint/07-application-security.md +++ b/sec-blueprint/07-application-security.md @@ -14,6 +14,7 @@ layout: techdoc {:toc} ## Application Definition + The term of Application (Apps) has a very wide coverage in AGL. To make it short, anything which is not in the core OS, is an App. @@ -21,12 +22,14 @@ Apps can be included in the base image or added after the fact, they can offer a 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. +**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 : @@ -41,7 +44,6 @@ In order to acheive an efficient containement multiple strategies are used : * End2end App author tracking and validation * Apps Privileges * Autiticated Apps to Apps/Services transport - ## Which protection are enforced on an App @@ -49,6 +51,7 @@ In order to acheive an efficient containement multiple strategies are used : 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. @@ -58,14 +61,18 @@ It is the first section the chain of trust for providing valid information to th ### 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. +**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. @@ -73,6 +80,7 @@ Within this limitation Apps (which can be a only a service) can still offer serv ### 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 @@ -91,6 +99,7 @@ We just need to be sure that means to deactivate those protections are removed f 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. @@ -100,26 +109,23 @@ The second requires a duplication of some API in order to be able to keep the fi 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) +* 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 index 12be18f..76f9e54 100644 --- a/sec-blueprint/08-Hardening.md +++ b/sec-blueprint/08-Hardening.md @@ -11,29 +11,26 @@ layout: techdoc **Table of Content** 1. TOC + {:toc} -Overview -======== +# Overview -Scope ------ +## Scope The information contained in this document is applicable to systems based on Automotive Grade Linux. -Limitations ------------ +## 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. +* 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. +* Some kernel configuration options can have an impact on performance. + This will be noted where applicable. -Document Structure ------------------- +## Document Structure This document has been divided into three sections; REQUIREMENTS, RECOMMENDATIONS, and VALIDATION. The REQUIREMENTS section details @@ -45,8 +42,7 @@ The third section, VALIDATION, provides reference scripts and test procedures th can be used to verify adherence with the REQUIREMENTS detailed in the first section of this guide. -Hardening ---------- +## Hardening The term *Hardening* refers to the tools, techniques and processes required in order to reduce the attack surface on an embedded system, @@ -70,30 +66,29 @@ and configuration of the root filesystem. release of user space applications, in order to reduce the number of attack surfaces used by potential attackers. -Secure Boot Software Flow Steps -------------------------------- +## Secure Boot Software Flow Steps -1. After power on, the processor will perform the verification - of the Stage 1 boot image, the stage 2 boot image and the Secure - loader image. +1. After power on, the processor will perform the verification + of the Stage 1 boot image, the stage 2 boot image and the Secure + loader image. - a. If any of the images fail the verification process the device - will not boot. + a. If any of the images fail the verification process the device + will not boot. -2. Upon successful verification of all of the boot and loader images, +1. Upon successful verification of all of the boot and loader images, the secure process will initiate the Stage 1 boot process. -3. The Stage 1 boot process will perform processor initialization, and - then initiate the Stage 2 boot process. +1. The Stage 1 boot process will perform processor initialization, and + then initiate the Stage 2 boot process. -4. The Stage 2 boot process will initiate the Secure Loader, which will - process any customer specific customizations (e.g. front panel - of ECU, USB based image updates, etc). +1. The Stage 2 boot process will initiate the Secure Loader, which will + process any customer specific customizations (e.g. front panel + of ECU, USB based image updates, etc). -5. The Secure Loader will check to determine if there are any updates - to be processed. If the update settings indicate that an upgrade - should occur then the Secure Loader will will determine the correct - action based on the nature of the upgrades: +1. The Secure Loader will check to determine if there are any updates + to be processed. If the update settings indicate that an upgrade + should occur then the Secure Loader will will determine the correct + action based on the nature of the upgrades: a. If the Secure Loader determines that an upgrade was performed (or attempted), it will initiate the reboot process. @@ -101,23 +96,22 @@ Secure Boot Software Flow Steps b. If no upgrades were processed: then the Secure Loader will pass control back to the Stage 2 boot process for further processing -6. The Stage 2 boot process will continue with the boot process, by +1. The Stage 2 boot process will continue with the boot process, by performing a verification of the kernel image prior to the load of that image a. If the kernel image verification fails, the Stage 2 boot loader will not boot -8. The Stage 2 boot loader will load the successfully verified kernel - and boot the linux OS +1. The Stage 2 boot loader will load the successfully verified kernel + and boot the linux OS -9. The booted Linux OS will perform the normal Linux init sequence +1. The booted Linux OS will perform the normal Linux init sequence -10. The Linux init process will start the required applications and - services as described in the init process and present on the rootfs. +1. The Linux init process will start the required applications and + services as described in the init process and present on the rootfs. -Requirements -============ +## 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 @@ -125,8 +119,7 @@ Requirements These requirements must still be met by manufacturers that opt to build using an alternative version of the Linux kernel. -Hardened Boot -------------- +## Hardened Boot ### Boot image selection @@ -145,7 +138,7 @@ feature is available from U-Boot 2013.07 version. To enable the secure boot feature, enable the following features: -``` +```bash CONFIG_FIT: enables support for Flat Image Tree (FIT) uImage format. CONFIG_FIT_SIGNATURE: enables signature verification of FIT images. CONFIG_RSA: enables RSA algorithm used for FIT image verifitcation. @@ -163,7 +156,7 @@ image. It shall use RSA2048 and SHA256 for authentication. To disable USB support in U-Boot, following configs shall not be defined: -``` +```bash CONFIG_CMD_USB: enables basic USB support and the usb command CONFIG_USB_UHCI: defines the lowlevel part. CONFIG_USB_KEYBOARD: enables the USB Keyboard @@ -176,7 +169,7 @@ CONFIG_USB_HOST_ETHER: enables USB ethernet adapter support Serial console output shall be disabled. To disable console output in U-Boot, set the following macros: -``` +```bash CONFIG_SILENT_CONSOLE CONFIG_SYS_DEVICE_NULLDEV CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC @@ -186,7 +179,7 @@ and set “***silent”*** environment variable. For the Secure loader, disable the traces by undefining the below macro -``` +```bash INC_DEBUG_PRINT ``` @@ -222,7 +215,7 @@ default environment variable and not in non-volatile memory. Remove configuration options related to non-volatile memory such as: -``` +```bash #define CONFIG_ENV_IS_IN_MMC #define CONFIG_ENV_IS_IN_EEPROM #define CONFIG_ENV_IS_IN_FLASH @@ -239,12 +232,11 @@ Remove configuration options related to non-volatile memory such as: and include the following definition: -``` +```bash #define** CONFIG_ENV_IS_NOWHERE ``` -Kernel Hardening ----------------- +## Kernel Hardening The following sub-sections contain information on various kernel configuration options to enhance the security measures in the kernel @@ -279,7 +271,7 @@ Kernel Hardening applications, the following kernel option should be set in the compile-time kernel configuration: -``` +```bash CONFIG_DEVKMEM=n ``` @@ -439,6 +431,7 @@ Kernel Hardening ```bash CONFIG_SWAP=n +``` ### Disable NFS file system @@ -546,28 +539,23 @@ Kernel Hardening ```bash CONFIG_MODULE_FORCE_LOAD=n ``` + ### System Services #### Console & Remote Access -- The kernel console interfaces shall be disabled. Do not pass any statements - of the following kind (e.g. console=ttyS0 console=tty0) on the kernel - command line. All of the console=<interface> statements should be - stripped and removed from the kernel command line. - -- The telnet server shall be disabled. - -- Do not start telnetd in init scripts. - -- Remove telnetd from the root file system. - -- Root login access via the console shall be disabled. - -- Do not run shell or getty on /dev/ttySx or /dev/console from - init scripts. - -- Root login access through remote access such as SSH shall - be disabled or completely removed +* The kernel console interfaces shall be disabled. Do not pass any statements + of the following kind (e.g. console=ttyS0 console=tty0) on the kernel + command line. All of the console=<interface> statements should be + stripped and removed from the kernel command line. +* The telnet server shall be disabled. +* Do not start telnetd in init scripts. +* Remove telnetd from the root file system. +* Root login access via the console shall be disabled. +* Do not run shell or getty on /dev/ttySx or /dev/console from + init scripts. +* Root login access through remote access such as SSH shall + be disabled or completely removed #### Disable *sudo* for other users @@ -587,46 +575,46 @@ Kernel Hardening #### User Account Management - All user accounts shall have strong, non-default passwords. A strong - password is described to have all of the following attributes: +All user accounts shall have strong, non-default passwords. +A strong password is described to have all of the following attributes: -- At least one upper-case letter +* At least one upper-case letter -- At least one numeric character +* At least one numeric character -- At least one lower-case letter +* At least one lower-case letter -- Password shall be eight or more characters in length +* Password shall be eight or more characters in length -- Shall not use a known, common pattern (e.g. Xxxxxxx\# - or Xxxxxxx\#\#) +* Shall not use a known, common pattern (e.g. Xxxxxxx\# + or Xxxxxxx\#\#) #### Remove known insecure services The following legacy services are inherently insecure and should be avoided: -- rlogind +* rlogind -- rshd +* rshd -- rcmd +* rcmd -- rexecd +* rexecd -- rbootd +* rbootd -- rquotad +* rquotad -- rstatd +* rstatd -- rusersd +* rusersd -- rwalld +* rwalld -- rhosts +* rhosts -- rexd +* rexd These services offer insufficient authentication, no encryption, and are not considered secure. They shall be removed along with their @@ -640,51 +628,51 @@ Kernel Hardening non-exhaustive sample of commonly used utilities that are part of the mtd-utils package: -- flash\_erase +* flash\_erase -- flash\_eraseall +* flash\_eraseall -- flashcp +* flashcp -- flash\_lock +* flash\_lock -- flash\_otp\_dump +* flash\_otp\_dump -- flash\_otp\_info +* flash\_otp\_info -- flash\_unlock +* flash\_unlock -- mkfs.jffs2 +* mkfs.jffs2 -- mkfs.ubifs +* mkfs.ubifs -- nanddump +* nanddump -- nandtest +* nandtest -- nandwrite +* nandwrite -- ubiattach +* ubiattach -- ubicrc32 +* ubicrc32 -- ubidetach +* ubidetach -- ubiformat +* ubiformat -- ubimkvol +* ubimkvol -- ubinfo +* ubinfo -- ubinize +* ubinize -- ubirename +* ubirename -- ubirmvol +* ubirmvol -- ubirsvol +* ubirsvol -- ubiupdatevol +* ubiupdatevol The mtd-utils package as a whole (including all of its executable binaries) shall not be present on the file system. Including these @@ -721,7 +709,6 @@ Kernel Hardening The following flags shall be used for mounting common filesystems: - | Partition | Notes | |------------------------------|---------------------------------------------------------------------------------------------| | /boot | Use nosuid and nodev and consider using noexec. | @@ -734,10 +721,8 @@ Kernel Hardening | | Note: if CONFIG\_DEVTMPFS\_MOUNT is set then the kernel will mount /dev and will not apply | | | the nosuid, noexec options. Either disable CONFIG\_DEVTMPFS\_MOUNT or add a remount with | | | noexec and nosuid options to system startup. | - -Recommendations -=============== +## Recommendations The following sections detail best practices that should be applied in order to secure a device. @@ -746,8 +731,7 @@ requirements, they may be upgraded to requirements status in the future. In addition, specific operators may change some of these recommendations into requirements based on their specific needs and objectives. -Hardened Boot -------------- +### Hardened Boot The boot loader consists of the Primary boot loader residing in OTP memory, sboot, U-Boot and Secure loader residing in external flash (NAND @@ -762,7 +746,7 @@ Kernel/system image before passing control to it. In U-Boot, following commands shall be disabled to avoid memory dumps -``` +```bash md : Memory Display command mm : Memory modify command – auto incrementing address @@ -794,8 +778,7 @@ to be disabled. Similarly sboot should disable flash access support through command line if any. -Hardened System ---------------- +## Hardened System ### Network @@ -805,7 +788,7 @@ Hardened System enabled services should be restricted to only those described in the STB’s functional description. -### Remove or Disable Unnecessary Services, Ports, and Devices. +### Remove or Disable Unnecessary Services, Ports, and Devices Services and utilities that do not have a defined purpose on a system should be removed. If removal is not possible, but the service or @@ -829,8 +812,7 @@ Hardened System Whether or not the filesystems are mounted in userspace(FUSE), restricted mount options should be observed. -Kernel Hardening ----------------- +## Kernel Hardening The following sub-sections contain information on various kernel configuration options that will require updating to a newer kernel @@ -896,6 +878,7 @@ Kernel Hardening This configuration is supported in Linux 3.5 and greater and thus should only be disabled for such versions. + ```bash CROSS_MEMORY_ATTACH=n ``` @@ -1025,35 +1008,43 @@ applications to avoid stack smashing, buffer overflow attacks. ### Stack Smashing Attacks - **-fstack-protector-all** - - Emit extra code to check for buffer overflows, such as stack smashing - attacks +```c +**-fstack-protector-all** +``` + +Emit extra code to check for buffer overflows, such as stack smashing attacks ### Position Independent Executables - **-pie –fpic** - - Produce a position independent executable on targets which supports - it. +```c +**-pie –fpic**: +``` + +Produce a position independent executable on targets which supports it. ### Detect Buffer Overflows - **-D\_FORTIFY\_SOURCE=2** - - Helps detect some buffer overflow errors. +```c +**-D\_FORTIFY\_SOURCE=2**: +``` + +Helps detect some buffer overflow errors. ### Prevent Overwrite Attacks - **–z,relro** - +```c +**–z,relro** +``` + This linking option helps during program load, several ELF memory sections need to be written by the linker, but can be turned read-only before turning over control to the program. This prevents some Global Offset Table GOT overwrite attacks, or in the dtors section of the ELF binary. - - **-z,now** + +```c +**-z,now** +``` During program load, all dynamic symbols are resolved, allowing for the complete GOT to be marked read-only (due to -z relro above). This @@ -1063,14 +1054,15 @@ resolved, but this shouldn't be an issue for daemons. ### Library linking - **–static** +```c +**–static** +``` It is recommended that dynamic linking should not be allowed. This will avoid user from replacing a library with malicious library. All libraries should be linked statically. -Removal or Non-Inclusion of Utilities -------------------------------------- +## Removal or Non-Inclusion of Utilities Table below lists utilities that are typically present in an embedded device, along with the normal path of each utility. The table has @@ -1119,8 +1111,7 @@ utilities are not required by the device then those should be removed. **sed, awk, cut, df, dmesg, echo, fdisk, grep, mkdir, mount (vfat), printf, tail, tee, test (directory), test (file)** -Root Access ------------- +## Root Access The main applications, those that provide the principal functionality of the embedded device, **should not execute** with root identity or any @@ -1143,7 +1134,7 @@ the same resources at the same time. Root access **should not be allowed** for the following utilities: -``` +```bash login su ssh @@ -1158,8 +1149,7 @@ user accounts. Switching to elevated privileges shall be allowed in the development environment via sudo. -Network Hardening ------------------ +## Network Hardening ### Disable IPv4 Forwarding @@ -1234,14 +1224,11 @@ Network Hardening SYN requests with the appropriate SYN+ACK reply, but it does not store the connection in its backlog queue. +## Validation -Validation -========== - -Hardened System ---------------- +### Hardened System -### Image Security Analysis Framework (ISAFW) +#### 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. @@ -1251,12 +1238,12 @@ 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 + <https://github.com/01org/isafw> This layer can be added to your builds to produce an analysis report, including a kernel config analysis. -### Usage +#### Usage In order to enable the isafw during the image build, please add the following line to your build/conf/local.conf file: diff --git a/sec-blueprint/index.md b/sec-blueprint/index.md index 9135a43..e20c2aa 100644 --- a/sec-blueprint/index.md +++ b/sec-blueprint/index.md @@ -8,7 +8,6 @@ layout: techdoc --- - ## [Overview](./01-overview.html) ## [Plateform Security](./02-plateform-security.html) |