diff options
Diffstat (limited to 'sec-blueprint/07-application-security.md')
| -rw-r--r-- | sec-blueprint/07-application-security.md | 50 |
1 files changed, 28 insertions, 22 deletions
diff --git a/sec-blueprint/07-application-security.md b/sec-blueprint/07-application-security.md index 09eb3e4..2c757b0 100644 --- a/sec-blueprint/07-application-security.md +++ b/sec-blueprint/07-application-security.md @@ -14,6 +14,7 @@ layout: techdoc {:toc} ## Application Definition + The term of Application (Apps) has a very wide coverage in AGL. To make it short, anything which is not in the core OS, is an App. @@ -21,12 +22,14 @@ Apps can be included in the base image or added after the fact, they can offer a In AGL, most of the middleware will be treated as Apps. ## Apps must be installed + Undependently of the fact that Apps are delivered with the base image or later installed on a running image, Apps are installed under the control of the Application Framework (AppFW). A special off-line mode of the AppFW, allows to install Apps at image creation.\* -**\* Note :** In early release, default Apps are installed on the image at first boot. +**Note :** In early release, default Apps are installed on the image at first boot. ## App containement + Apps are running in isolation of the system and other Apps. In order to acheive an efficient containement multiple strategies are used : @@ -41,7 +44,6 @@ In order to acheive an efficient containement multiple strategies are used : * End2end App author tracking and validation * Apps Privileges * Autiticated Apps to Apps/Services transport - ## Which protection are enforced on an App @@ -49,6 +51,7 @@ In order to acheive an efficient containement multiple strategies are used : The AGL App development process enforces of the level of autorisation given to an App developper and tracks that autorisation level end2end. Depending of the implementation, the tracking may be : + * static, simply enforced at the registration of the App on the repository or dynamic. * dynamic, track and verified at installation by the AppFW. @@ -58,14 +61,18 @@ It is the first section the chain of trust for providing valid information to th ### Platform security configuration The AppFW derives from the Meta data received with the App at delivery, which privileges will be granted to this App : + * Max CPU, RAM, IO, ... * Firewall configuration * Name spaces ... + It will create the directories required for the App following the Smack rules described in the "Platform Security" blueprint as well as the associated systemd config files to be used by the launcher. As the platform securities services are static for a given release of the OS, the mapping remains simple. -**Important** -* An App cannot change the CoreOS. +**Important**: + +* An App cannot change the CoreOS. + It s not allowed for an App to modify or add an element to the CoreOS. Like with containers App are required to embed all the code required for their operation. Within this limitation Apps (which can be a only a service) can still offer services to other App by the mean of AGL binders which use the autenticated AGL transport. @@ -73,6 +80,7 @@ Within this limitation Apps (which can be a only a service) can still offer serv ### AGL Platform protections By default AGL provides three specific protection services : + * Privilege management and enforment via cynara * Autenticated transport (via AGL binders, websocket and Oauth2) * App origin validation @@ -91,6 +99,7 @@ We just need to be sure that means to deactivate those protections are removed f AGL Platform protections are mostly enforced by dedicated middleware which are protected by the platform securities. Some more risky zones are identified : + * the creation of binding where an App could create a look a like binding that does not respect any protection. * services which provide a wide range of service and need to restict the user request following his profile. @@ -100,26 +109,23 @@ The second requires a duplication of some API in order to be able to keep the fi The side effect of this complexity will impose to create an introspection mode where there is the possibility to verify all the API offered by an App and which privileges are required to activate them. ### Privilege grouping + In order keep the concept of White listing manageable, a privilege hiercharchy is used. A small example shoudl clarify that concept. - - System:Com:SMS:notify - - System:Com:SMS:list - - System:Com:SMS:display - - System:Com:SMS:send - - System:Com:SMS:transfer - - System:Com:SMS:* (the * requires to be explicit on global capability request) - - - System:Com:Phone:notify - - System:Com:Phone:list - - System:Com:Phone:display - - System:Com:Phone:send - - System:Com:Phone:transfer - - System:Com:Phone:* - - - System:Com:* (includes SMS:* & Phone:*) - - - - System:Com:*:notify (includes SMS:notify & Phone:notify) +* System:Com:SMS:notify +* System:Com:SMS:list +* System:Com:SMS:display +* System:Com:SMS:send +* System:Com:SMS:transfer +* System:Com:SMS: (*the* requires to be explicit on global capability request) +* System:Com:Phone:notify +* System:Com:Phone:list +* System:Com:Phone:display +* System:Com:Phone:send +* System:Com:Phone:transfer +* System:Com:Phone:* +* System:Com:* (includes SMS:* & Phone:*) +* System:Com:*:notify (includes SMS:notify & Phone:notify) That last concept might be too complex to implement and real usefulness should be validated. |