blob: 9f67b16fa2821a669334251b46a7ef0685fc6d4e (
plain)
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
|
# Application framework/model (**AppFw**)
The application framework manages:
- The applications and services management: Installing, Uninstalling, Listing, ...
- The life cycle of applications: Start -> (Pause, Resume) -> Stop.
- Events and signals propagation.
- Privileges granting and checking.
- API for interaction with applications.
<!-- note -->
- The **security model** refers to the security model used to ensure security
and to the tools that are provided for implementing that model. It's an
implementation detail that should not impact the layers above the application
framework.
- The **security model** refers to how **DAC** (Discretionary Access Control),
**MAC** (Mandatory Access Control) and Capabilities are used by the system to
ensure security and privacy. It also includes features of reporting using
audit features and by managing logs and alerts.
<!-- endnote -->
The **AppFw** uses the security model to ensure the security and the privacy of
the applications that it manages. It must be compliant with the underlying
security model. But it should hide it to the applications.
<!-- config -->
Domain | Object | Recommendations
---------------------- | -------------- | --------------------------------
Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model.
<!-- endconfig -->
See [AGL AppFw Privileges Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) and [AGL - Application Framework Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf) for more
information.
<!-- pagebreak -->
## Cynara
There's a need for another mechanism responsible for checking applicative
permissions: Currently in AGL, this task depends on a policy-checker service
(**Cynara**).
- Stores complex policies in databases.
- "Soft" security (access is checked by the framework).
Cynara interact with **D-Bus** in order to deliver this information.
<!-- config -->
Domain | Object | Recommendations
----------------------- | ----------- | -------------------------------------
Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service.
<!-- endconfig -->
### Policies
- Policy rules:
- Are simple - for pair [application context, privilege] there is straight
answer (single Policy Type): [ALLOW / DENY / ...].
- No code is executed (no script).
- Can be easily cached and managed.
- Application context (describes id of the user and the application credentials)
It is build of:
- UID of the user that runs the application.
- **SMACK** label of application.
## Holding policies
Policies are kept in buckets. Buckets are set of policies which have additional
a property of default answer, the default answer is yielded if no policy matches
searched key. Buckets have names which might be used in policies (for directions).
|
