docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.1_Mandatory_Access_Control.md

   1 ---
   2 edit_link: ''
   3 title: Mandatory Access Control
   4 origin_url: >-
   5   https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-5/1-MAC.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 # Mandatory Access Control
  11
  12 <!-- section-note -->
  13
  14 We decided to put the **MAC** protection on the platform part despite the fact
  15 that it applies to the kernel too, since its use will be mainly at the platform
  16 level (except floor part).
  17
  18 <!-- end-section-note -->
  19
  20 **M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the
  21 Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL
  22 uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol
  23 **K**ernel (**SMACK**). This protection involves the creation of **SMACK**
  24 labels as part of the extended attributes **SMACK** labels to the file extended
  25 attributes. And a policy is also created to define the behaviour of each label.
  26
  27 The kernel access controls is based on these labels and this policy. If there
  28 is no rule, no access will be granted and as a consequence, what is not
  29 explicitly authorized is forbidden.
  30
  31 There are two types of **SMACK** labels:
  32
  33 - **Execution SMACK** (Attached to the process): Defines how files are
  34   _accessed_ and _created_ by that process.
  35 - **File Access SMACK** (Written to the extended attribute of the file): Defines
  36   _which_ process can access the file.
  37
  38 By default a process executes with its File Access **SMACK** label unless an
  39 Execution **SMACK** label is defined.
  40
  41 AGL's **SMACK** scheme is based on the _Tizen 3 Q2/2015_. It divides the System
  42 into the following domains:
  43
  44 - Floor.
  45 - System.
  46 - Applications, Services and User.
  47
  48 See [AGL security framework review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf) and [Smack White Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf)
  49 for more information.
  50
  51 --------------------------------------------------------------------------------
  52
  53 <!-- pagebreak -->
  54
  55 ## Floor
  56
  57 The _floor_ domain includes the base system services and any associated data and
  58 libraries. This data remains unchanged at runtime. Writing to floor files or
  59 directories is allowed only in development mode or during software installation
  60 or upgrade.
  61
  62 The following table details the _floor_ domain:
  63
  64 Label | Name  | Execution **SMACK** | File Access **SMACK**
  65 ----- | ----- | ------------------- | ---------------------------------------
  66 `-`   | Floor | `r-x` for all       | Only kernel and internal kernel thread.
  67 `^`   | Hat   | `---` for all       | `rx` on all domains.
  68 `*`   | Star  | `rwx` for all       | None
  69
  70 <!-- section-note -->
  71
  72 - The Hat label is Only for privileged system services (currently only
  73   systemd-journal). Useful for backup or virus scans. No file with this label
  74   should exist except in the debug log.
  75
  76 - The Star label is used for device files or `/tmp` Access restriction managed
  77   via **DAC**. Individual files remain protected by their **SMACK** label.
  78
  79 <!-- end-section-note --> <!-- section-config -->
  80
  81 Domain             | `Label` name | Recommendations
  82 ------------------ | ------------ | -----------------------------------------------------------
  83 Kernel-MAC-Floor-1 | `^`          | Only for privileged system services.
  84 Kernel-MAC-Floor-2 | `*`          | Used for device files or `/tmp` Access restriction via DAC.
  85
  86 <!-- end-section-config -->
  87
  88 --------------------------------------------------------------------------------
  89
  90 <!-- pagebreak -->
  91
  92 ## System
  93
  94 The _system_ domain includes a reduced set of core system services of the OS and
  95 any associated data. This data may change at runtime.
  96
  97 The following table details the _system_ domain:
  98
  99 Label            | Name      | Execution **SMACK**                             | File Access **SMACK**
 100 ---------------- | --------- | ----------------------------------------------- | ---------------------
 101 `System`         | System    | None                                            | Privileged processes
 102 `System::Run`    | Run       | `rwxatl` for User and System label              | None
 103 `System::Shared` | Shared    | `rwxatl` for system domain `r-x` for User label | None
 104 `System::Log`    | Log       | `rwa` for System label `xa` for user label      | None
 105 `System::Sub`    | SubSystem | Subsystem Config files                          | SubSystem only
 106
 107 <!-- section-config -->
 108
 109 Domain              | `Label` name     | Recommendations
 110 ------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------
 111 Kernel-MAC-System-1 | `System`         | Process should write only to file with transmute attribute.
 112 Kernel-MAC-System-2 | `System::run`    | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`.
 113 Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege.
 114 Kernel-MAC-System-4 | `System::Log`    | Some limitation may impose to add `w` to enable append.
 115 Kernel-MAC-System-5 | `System::Sub`    | Isolation of risky Subsystem.
 116
 117 <!-- end-section-config -->
 118
 119 --------------------------------------------------------------------------------
 120
 121 <!-- pagebreak -->
 122
 123 ## Applications, Services and User
 124
 125 The _application_, _services_ and _user_ domain includes code that provides
 126 services to the system and user, as well as any associated data. All code
 127 running on this domain is under _Cynara_ control.
 128
 129 The following table details the _application_, _services_ and _user_ domain:
 130
 131 Label               | Name   | Execution **SMACK**                                                         | File Access **SMACK**
 132 ------------------- | ------ | --------------------------------------------------------------------------- | ---------------------------
 133 `User::Pkg::$AppID` | AppID  | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App
 134 `User::Home`        | Home   | `rwx-t` from System label `r-x-l` from App                                  | None
 135 `User::App-Shared`  | Shared | `rwxat` from System and User domains label of $User                         | None
 136
 137 <!-- section-config -->
 138
 139 Domain              | `Label` name        | Recommendations
 140 ------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------
 141 Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode.
 142 Kernel-MAC-System-2 | `User::Home`        | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute.
 143 Kernel-MAC-System-3 | `User::App-Shared`  | Shared space between all App running for a given user.
 144
 145 <!-- end-section-config -->
 146
 147 ## Attack Vectors
 148
 149 There are 4 major components to the system:
 150
 151 - The LSM kernel module.
 152 - The `smackfs` filesystem.
 153 - Basic utilities for policy management and checking.
 154 - The policy/configuration data.
 155
 156 As with any mandatory access system, the policy management needs to be carefully separated
 157 from the checking, as the management utilities can become a convenient point of attack.
 158 Dynamic additions to the policy system need to be carefully verified, as the ability to
 159 update the policies is often needed, but introduces a possible threat. Finally,
 160 even if the policy management is well secured, the policy checking and failure response
 161 to that checking is also of vital importance to the smooth operation of the system.
 162
 163 While **MAC** is a certainly a step up in security when compared to DAC, there are still
 164 many ways to compromise a SMACK-enabled Linux system. Some of these ways are as follows:
 165
 166 - Disabling SMACK at invocation of the kernel (with command-line: security=none).
 167 - Disabling SMACK in the kernel build and redeploying the kernel.
 168 - Changing a SMACK attribute of a file or directory at install time.
 169 - Tampering with a process with the CAP_MAC_ADMIN privilege.
 170 - Setting/Re-setting the SMACK label of a file.
 171 - Tampering with the default domains (i.e. /etc/smack/accesses.d/default-access-domains).
 172 - Disabling or tampering with the SMACK filesystem (i.e. /smackfs).
 173 - Adding policies with `smackload` (adding the utility if not present).
 174 - Changing labels with `chsmack` (adding the utility if not present).