---
-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.
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 -->
## 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.
--------------------------------------------------------------------------------
Code Review / AGL / documentation.git / blobdiff