docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md

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