diff options
Diffstat (limited to 'docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md')
| -rw-r--r-- | docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md new file mode 100644 index 0000000..db911d2 --- /dev/null +++ b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md @@ -0,0 +1,112 @@ +--- +edit_link: '' +title: Introduction +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-5/0_Abstract.md +--- + +<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/architecture/master/security_blueprint-security-blueprint-book.yml --> + +# Part 5 - Platform + +## Abstract + +The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services. +The platform includes the following software: + +- Linux **BSP** configured for reference boards. +- Proprietary device drivers for common peripherals on reference boards. +- Application framework. +- Windows/layer management (graphics). +- Sound resource management. +- An atomic software update system (chapter Update). +- Building and debug tools (based on Yocto project). + +<!-- section-todo --> + +Domain | Improvement +------------------- | -------------------------------- +Platform-Abstract-1 | Create a graphics and sound part. + +<!-- end-section-todo --> + +This part focuses on the AGL platform including all tools and techniques used to +upgrade the security and downgrade the danger. It must be possible to apply the +two fundamental principles written at the very beginning of the document. First +of all, security management must remain simple. You must also prohibit +everything by default, and then define a set of authorization rules. As cases +to deal with, we must: + +- Implement a **MAC** for processes and files. +- Limit communication between applications (_SystemBus_ and _SystemD_ part). +- Prohibit all tools used during development mode (_Utilities_ and _Services_ part). +- Manage user capabilities (_Users_ part). +- Manage application permissions and policies (_AGLFw_ part). + +<!-- section-note --> + +The tools and concepts used to meet these needs are only examples. +Any other tool that meets the need can be used. + +<!-- end-section-note --> + +In AGL, as in many other embedded systems, different security mechanisms settle +in the core layers to ensure isolation and data privacy. While the Mandatory +Access Control layer (**SMACK**) provides global security and isolation, other +mechanisms like **Cynara** are required to check application's permissions at +runtime. Applicative permissions (also called "_privileges_") may vary depending +on the user and the application being run: an application should have access to +a given service only if it is run by the proper user and if the appropriate +permissions are granted. + +## Discretionary Access Control + +**D**iscretionary **A**ccess **C**ontrol (**DAC**) is the traditional Linux method of separating +users and groups from one another. In a shared environment where multiple users +have access to a computer or network, Unix IDs have offered a way to contain access +within privilege areas for individuals, or shared among the group or system. +The Android system took this one step further, assigning new user IDs for each App. +This was never the original intention of Linux UIDs, but was able to provide +Android’s initial security element: the ability to sandbox applications. + +Although AGL mentions use of **DAC** for security isolation, the weight of the +security responsibility lies in the **M**andatory **A**ccess **C**ontrol (**MAC**) and **Cynara**. +Furthermore, there are system services with unique UIDs. however,the system +does not go to the extreme of Android, where every application has its own UID. +All sandboxing (app isolation) in AGL is handled in the **MAC** contexts. + +## Mandatory Access Control + +**M**andatory **A**ccess **C**ontrol (**MAC**) is an extension to **DAC**, +whereby extended attributes (xattr) are associated with the filesystem. +In the case of AGL, the smackfs filesystem allows files and directories +to be associated with a SMACK label, providing the ability of further +discrimination on access control. A SMACK label is a simple null terminated +character string with a maximum of 255 bytes. While it doesn’t offer the +richness of an SELinux label, which provides a user, role,type, and level, +the simplicity of a single value makes the overall design far less complex. +There is arguably less chance of the security author making mistakes in the policies set forth. + +-------------------------------------------------------------------------------- + +<!-- pagebreak --> + +## Acronyms and Abbreviations + +The following table lists the terms utilized within this part of the document. + +Acronyms or Abbreviations | Description +------------------------- | -------------------------------------------------------------- +_ACL_ | **A**ccess **C**ontrol **L**ists +_alsa_ | **A**dvanced **L**inux **S**ound **A**rchitecture +_API_ | **A**pplication **P**rogramming **I**nterface +_AppFw_ | **App**lication **F**rame**w**ork +_BSP_ | **B**oard **S**upport **P**ackage +_Cap_ | **Cap**abilities +_DAC_ | **D**iscretionary **A**ccess **C**ontrol +_DDOS_ | **D**istributed **D**enial **O**f **S**ervice +_DOS_ | **D**enial **O**f **S**ervice +_IPC_ | **I**nter-**P**rocess **C**ommunication +_MAC_ | **M**andatory **A**ccess **C**ontrol +_PAM_ | **P**luggable **A**uthentication **M**odules +_SMACK_ | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel |