docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.0_Abstract.md

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