docs/1_Architecture_Guides/1.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md

   1 ---
   2 edit_link: ''
   3 title: Introduction
   4 origin_url: >-
   5   https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-5/0_Abstract.md
   6 ---
   7
   8 <!-- 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 -->
   9
  10 # Part 5 - Platform
  11
  12 ## Abstract
  13
  14 The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services.
  15 The platform includes the following software:
  16
  17 - Linux **BSP** configured for reference boards.
  18 - Proprietary device drivers for common peripherals on reference boards.
  19 - Application framework.
  20 - Windows/layer management (graphics).
  21 - Sound resource management.
  22 - An atomic software update system (chapter Update).
  23 - Building and debug tools (based on Yocto project).
  24
  25 <!-- section-todo -->
  26
  27 Domain              | Improvement
  28 ------------------- | --------------------------------
  29 Platform-Abstract-1 | Create a graphics and sound part.
  30
  31 <!-- end-section-todo -->
  32
  33 This part focuses on the AGL platform including all tools and techniques used to
  34 upgrade the security and downgrade the danger. It must be possible to apply the
  35 two fundamental principles written at the very beginning of the document. First
  36 of all, security management must remain simple. You must also prohibit
  37 everything by default, and then define a set of authorization rules. As cases
  38 to deal with, we must:
  39
  40 - Implement a **MAC** for processes and files.
  41 - Limit communication between applications (_SystemBus_ and _SystemD_ part).
  42 - Prohibit all tools used during development mode (_Utilities_ and _Services_ part).
  43 - Manage user capabilities (_Users_ part).
  44 - Manage application permissions and policies (_AGLFw_ part).
  45
  46 <!-- section-note -->
  47
  48 The tools and concepts used to meet these needs are only examples.
  49 Any other tool that meets the need can be used.
  50
  51 <!-- end-section-note -->
  52
  53 In AGL, as in many other embedded systems, different security mechanisms settle
  54 in the core layers to ensure isolation and data privacy. While the Mandatory
  55 Access Control layer (**SMACK**) provides global security and isolation, other
  56 mechanisms like **Cynara** are required to check application's permissions at
  57 runtime. Applicative permissions (also called "_privileges_") may vary depending
  58 on the user and the application being run: an application should have access to
  59 a given service only if it is run by the proper user and if the appropriate
  60 permissions are granted.
  61
  62 ## Discretionary Access Control
  63
  64 **D**iscretionary **A**ccess **C**ontrol (**DAC**) is the traditional Linux method of separating
  65 users and groups from one another. In a shared environment where multiple users
  66 have access to a computer or network, Unix IDs have offered a way to contain access
  67 within privilege areas for individuals, or shared among the group or system.
  68 The Android system took this one step further, assigning new user IDs for each App.
  69 This was never the original intention of Linux UIDs, but was able to provide
  70 Android’s initial security element: the ability to sandbox applications.
  71
  72 Although AGL mentions use of **DAC** for security isolation, the weight of the
  73 security responsibility lies in the **M**andatory **A**ccess **C**ontrol (**MAC**) and **Cynara**.
  74 Furthermore, there are system services with unique UIDs. however,the system
  75 does not go to the extreme of Android, where every application has its own UID.
  76 All sandboxing (app isolation) in AGL is handled in the **MAC** contexts.
  77
  78 ## Mandatory Access Control
  79
  80 **M**andatory **A**ccess **C**ontrol (**MAC**) is an extension to **DAC**,
  81 whereby extended attributes (xattr) are associated with the filesystem.
  82 In the case of AGL, the smackfs filesystem allows files and directories
  83 to be associated with a SMACK label, providing the ability of further
  84 discrimination on access control. A SMACK label is a simple null terminated
  85 character string with a maximum of 255 bytes. While it doesn’t offer the
  86 richness of an SELinux label, which provides a user, role,type, and level,
  87 the simplicity of a single value makes the overall design far less complex.
  88 There is arguably less chance of the security author making mistakes in the policies set forth.
  89
  90 --------------------------------------------------------------------------------
  91
  92 <!-- pagebreak -->
  93
  94 ## Acronyms and Abbreviations
  95
  96 The following table lists the terms utilized within this part of the document.
  97
  98 Acronyms or Abbreviations | Description
  99 ------------------------- | --------------------------------------------------------------
 100 _ACL_                     | **A**ccess **C**ontrol **L**ists
 101 _alsa_                    | **A**dvanced **L**inux **S**ound **A**rchitecture
 102 _API_                     | **A**pplication **P**rogramming **I**nterface
 103 _AppFw_                   | **App**lication **F**rame**w**ork
 104 _BSP_                     | **B**oard **S**upport **P**ackage
 105 _Cap_                     | **Cap**abilities
 106 _DAC_                     | **D**iscretionary **A**ccess **C**ontrol
 107 _DDOS_                    | **D**istributed **D**enial **O**f **S**ervice
 108 _DOS_                     | **D**enial **O**f **S**ervice
 109 _IPC_                     | **I**nter-**P**rocess **C**ommunication
 110 _MAC_                     | **M**andatory **A**ccess **C**ontrol
 111 _PAM_                     | **P**luggable **A**uthentication **M**odules
 112 _SMACK_                   | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel