diff options
author | 2020-10-30 10:23:28 +0530 | |
---|---|---|
committer | 2020-11-11 13:36:16 +0000 | |
commit | da6cd0b6c26ca9a3760d8a89ce68baf83eeaa1b1 (patch) | |
tree | 5621912c4960ff1919f4664f95f4c4f62b347e5d /docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md | |
parent | e76766d79c3063b873b75bd2080c654f3f6d71ba (diff) |
Added [in-progress] Developer Guides
Updated mkdocs.yml, README.md.
Text wrap markdowns at 80.
Bug-AGL: [SPEC-3633]
Signed-off-by: Shankho Boron Ghosh <shankhoghosh123@gmail.com>
Change-Id: I2d7b43cb870e97786d3eb101c60a2071cc50f0be
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25498
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
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 | 61 |
1 files changed, 30 insertions, 31 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 index db911d2..4074b6f 100644 --- 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 @@ -1,18 +1,14 @@ --- -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: +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. @@ -34,19 +30,20 @@ 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: +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). +- 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. +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 --> @@ -61,31 +58,33 @@ 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. +**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. +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. +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. -------------------------------------------------------------------------------- |