Adding file naming and indexing
[AGL/documentation.git] / docs / 03_Architecture_Guides / 02_Security_Blueprint / 07_Application.md
1 ---
2 title: Application
3 ---
4
5 **Application Hardening**: Best practices to apply to the build and release of
6 user space applications, in order to reduce the number of attack surfaces used
7 by potential attackers.
8
9 The term of Application (App) has a very wide definition in **AGL**. Almost
10 anything which is not in the core Operating System (OS) is an Application.
11 Applications can be included in the base software package (image) or can be
12 added at run-time.
13
14 Application containment is achieved using the following protections:
15
16 - Linux Native protection
17   - Mandatory Access Control (**MAC**)
18 - AGL Platform protections
19   - Origin Tracking and Validation
20   - Application Privilege Management and Enforcement via Cynara
21   - Authenticated Transport via D-Bus
22
23 ## Application Types
24
25 AGL provides a framework for applications to be written in different forms:
26
27 - Web application: HTML5 + JavaScript
28 - Qt application: in a QML file
29 - Native application: in C
30
31 While there is no harm in providing multiple types of applications, from a
32 security perspective this does increase the attack surface for an intruder. The
33 application framework (**AppFw**) consists of a number of utilities and daemons
34 which provide context for the applications. Isolation is provided through
35 **SMACK** labels.
36
37 ## Application Store
38
39 Although the Tizen system has defined a [system of App signing and signing
40 flow](https://wiki.tizen.org/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates)
41 to avoid the spread of unauthorized Apps that might contain malware. At this
42 point, it is unclear how much of this flow AGL will adopt. However, judging from
43 the experience, it is an essential topic. For example, the Google Play Store
44 controls the authorization of Apps through signing, and still, there are [many
45 accounts of Apps containing malware on the
46 store](http://www.eweek.com/mobile/researchers-find-132-malware-infected-android-apps-on-google-play).
47
48 Tizen defines 5 levels of certificates and signing at each level, including an
49 author, testing distributor, public level store distributor, partner level store
50 distributor, and platform level store distributor. AGL may define a different
51 number of third parties, but at a minimum an author and store distributor should
52 be defined.
53
54 ![App Signing Flow](images/App_signing_flow.png)
55
56 Once the number of signatures has been established, verification of those
57 signatures needs to be done at a minimum at installation time on the AGL device.
58 It is important to ensure the robustness/integrity of the public key used for
59 signature verification. If the public key is modified, then this compromised key
60 can be used to verify an attacker's private key signature.
61
62 Further to this, installation-time verification is limited. Attacks can happen
63 to apps in-memory at runtime. Any modifications made after installation will be
64 missed by installation-time verification. Integrity verification that runs
65 during execution makes for a more complete security story.
66
67 --------------------------------------------------------------------------------
68
69 ## Acronyms and Abbreviations
70
71 The following table lists the terms utilized within this part of the document.
72
73 Acronyms or Abbreviations | Description
74 ------------------------- | ----------------------------------------------------
75 _3GPP_                    | **3**rd **G**eneration **P**artnership **P**roject
76 _CASB_                    | **C**loud **A**ccess **S**ecurity **B**roker
77 _DAST_                    | **D**ynamic **A**pplication **S**ecurity **T**esting
78 _DPI_                     | **D**eep **P**acket **I**nspection
79 _IDS_                     | **I**ntrusion **D**etection **S**ystems
80 _IPS_                     | **I**ntrusion **P**revention **S**ystems
81 _IPSec_                   | **I**nternet **P**rotocol **Sec**urity
82 _LSM_                     | **L**inux **S**ecurity **M**odule
83 _MITM_                    | **M**an **I**n **T**he **M**iddle
84 _OSI_                     | **O**pen **S**ystems **I**nterconnection
85 _SATS_                    | **S**tatic **A**pplication **S**ecurity **T**esting
86
87 # Local
88
89 Domain                     | Improvement
90 -------------------------- | ------------------------------
91 Application-Installation-1 | Talk about AppFw offline mode.
92
93 ## Installation
94
95 Applications can be delivered and installed with the base image using a special
96 offline-mode provided by the **AppFw**. Apps can also be installed at run time.
97
98 During early release, default Apps are installed on the image at first boot.
99
100 Domain                     | Object    | Recommendations
101 -------------------------- | --------- | -----------------------------------------------------------------------
102 Application-Installation-1 | AppFw     | Provide offline-mode in order to install app with the base image.
103 Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good.
104
105 # Local
106
107 ## Privilege Management
108
109 Application privileges are managed by **Cynara** and the security manager in the
110 **AppFw**. For more details, please refer to the **AppFw** documentation in
111 Platform part.
112
113 # App Signature
114
115 Domain                  | Improvement
116 ----------------------- | ----------------------------------------------------------
117 Application-Signature-1 | Add content (see secure build in Secure development part).
118
119
120 # Services
121
122 Domain                 | Improvement
123 ---------------------- | ------------
124 Application-Services-1 | Add content (Which services?).
125 Application-Services-2 | Add Binder.