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

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