1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
---
title : platform Security
date : 2016-06-30
categories: architecture, automotive
tags: architecture, automotive, linux
layout: techdoc
---
**Table of Content**
1. TOC
{:toc}
## Platform Definition
The platform includes a set of HW supporting an AGL Linux distribution and AGL compliant Application and Services.
On the HW side this will include :
- a SoC
- RAM, ROM and Storage
- Peripherial
The AGL SW platform includes all the SW required after the initial boot loader in order to support AGL compliant applications and services :
- Linux BPS configured for the reference boards
- Set of drivers for the common peripherials available on the reference boards (they may not all be Open Source)
- Application Framework
- Windows/layer management to allow Application to gracefully share the displays
- Sound resource manager to allow Application to gracefully share the displays
- an atomic update system support / as read only and MAC (Smack)
- set of building and debug tools (based on yocto project)
## Secure boot
The secure boot is tighly linked to the SoC and will vary from SoC to SoC.
AGL does not provide the secure boot but AGL platform is designed to be able to operate with a secure boot.
## Certificate and Key Management
The default Key management provided by AGL is SoC independant and use leyrings. Thismodel is less secured than a SoC HW integrated model and we advise AGL adopters to activate HW support from their selected SoC as much as possible.
The activation of HW support for Key management if left to the integrator.
## Madatory Access Control configuration
The general Smack schema used by AGL is inspired from Tizen 3 Q2/2015
but tries to enable a better protection of code ran via run time (e.g.
JavaScript, Python) and enable Cloud/Device hybrid applications model.
It takes into account the Tizen2 experience of creating too complex MAC
rules and limit the use of MAC for process file access tracking leaving
the application capabilities management to other model (Cynara and the
Security manager).
https://wiki.tizen.org/wiki/Security/Overview\#Implementation\_in\_Tizen\_3.0\_2015.Q2
*You will notice that the Smack initial configuration described bellow,
even if not obvious to read, represents a manageable complexity which
should be understood in no more than a few hours.***
**
This initial Smack schema tries to clearly keep the differentiation
between the execution Smack label of a Process and the Smack label of a
file. The first one defines which file a process can access and how
files will be created by the process. The second defines which process
can access the file. By default a process will execute with its file
access Smack label but that can be overwritten by an execution Smack
label.
The system is split in 3 domains :
- **Floor**, which includes the base services and associated data and libraries of the OS which are unchanged during the execution of the OS. Outside of development mode, installation and upgrade software, no one is allowed to write in Floor files and directories.
- **System**; which includes a reduced set of core services of the OS and the data that they maintain. Those data are expected to change during the execution of the OS.
- **Apps, Services and User**, which includes code providing services to the system and user and their associated data. Per concept all code running in this domain are under strict control and isolation by the Cynara and Smacks rules.
**Floor Domain**
-------------------------------------------------------------------------------------------------------------------------
|Label| Name | File | Process | Comment |
|:-:|:-------|:-------------|:------------------------------------|:-----------------------------------------------------|
| |
| - | Floor | r-x for all | Only kernel and<br>internal kernel thread <br>| -- |
| ^ | Hat | --- for all | rx on all domains | only for privileged system Services (today only systemd-journal) useful for backup or virus scan. No file with that label should exist except debug log. |
| * | Star | rwx for all | None | used for device files or /tmp Access restriction managed via DAC. Individual files remain protected by their Smack label. |
**System Domain**
-------------------------------------------------------------------------------------------------------------------------
|Label| Name | File | Process | Comment |
|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------|
| |
|System|System|none|Privileged<br>processes|Process should only write on file with transmute attribute.|
|System::run|Run|rwxatl for User and System label|None|files are created with directory label<br>from user and system domain (transmute)<br>Lock is implicit with w.|
|System::shared|Shared|rwxatl for system domain<br>r-x for User label|None|files are created with directory label from system domain (transmute)<br>User domain has lock privilege|
|System::Log|Log|rwa for System label<br>xa for user label|None|Some limitation may impose to add w to enable append.|
|System::Sub|SubSystem|SubSystem Config files|SubSystem only|Isolation of risky SubSystem**|
*\*Runtime: IoT-OS AppFW always starts a new instance of the runtime for each application (no shared process model is allowed and change the runtime process label to the App Smack label)<br>
\*\* unconfined mode is reserved for future evolution.*
**Apps, services and User Domain**
-------------------------------------------------------------------------------------------------------------------------
|Label| Name | File | Process | Comment |
|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------|
| |
|App::$AppID|AppID|rwx (for files created by the App).<br>rx for files installed by AppFW|$App runtime<br>executing $App|One Label per App.<br>A data Dir is created by the AppFW in rwx.<br>Older releases still use User::App::$AppID |
|User::Home|Home|rwx-t from System label<br>r-x-l from App|None|AppFW needs to create Dir in /home/$USER/App-Shared at 1st launch if not present/ with label<br>app-data access="User::App-Shared"<br>without transmute.|
|App-Shared|Shared|rwxat from System and User domains label of $User|None|Shared space between all App running for a given user.<br>Older releases may still use User::App-Shared|
## Secured transport for Binder implementation
## Resource Management
## Trust Zone and Trusted Execution
Trusted zone and Trusted execution are services provided by the SoC vendors and services offered can varie even within the same familly of SoC depending of their configuration.
AGL platform does not provide any Trusted Zone or Tusted Execution direct support as these are specific to each indivual SoC but on the other side the AGL platform is architectured to ease the use of HW helpers.
In particular AGL advise whenever possible to take profit of HW helpers available to store critical data in the secure zone and to execute critical validatin code (in particular signature check) in trusted execution mode.
## Critical Resource Protection
## AGL Platform Software Update
AGL platform provides by default a software update module which is capable to respect the AHL platform update requirements:
- support Smack as MAC
- support read only / file system
- support integrity enforcement such as IMA and EVM.
-
Any update software respecting these requirement can be used. AGL advise strongly to only use solutions that enable a strong verification of the validity and integrity of the download update or upgrade what ever is the selected solution.
## cloud service infrastructure
|
