Overview of AGL the FLOSS embedded secured OS based on linux · 2018-10-10 · ACL Standard Linux...

Overview of AGL the FLOSS embedded

secured OS based on linux

9th October 2018

José Bollo Security Technical [email protected]

9th October 2018 overview of AGL, FLOSS embedded secured OS 2

IoT.bzh

Fulup Stéphane Manuel Yannick José

October 2015

October 2018

● Mostly dedicated to AGL

● https://iot.bzh/en/● http://github.com/iotbzh

LORIENT

vannes

https://iot.bzh/en/

http://github.com/iotbzh


Overview of AGL system


AGL 6.0 Funky Flounder

identity audio-4a

persistence

weather

unicens

nfcnetwork

mediascanner

mediaplayergeoclue

bluetooth

windowmanager

low-can

homescreen

LINUX KERNEL

AG

L fr

amew

ork

Sys

tem

D

(pulseaudio) Network-Manager ...

geocluebluez gstreamer

...

DASHBOARD HOMESCREEN LAUNCHER

MEDIAPLAYER HVAC MIXER

SETTINGS RADIO NAVI

PHONE POI ...

upstreamservices

AGLservices

AGL applications


Micro service architecture

APPLICATION

SECURITYCONTEXTC

SERVICE

SECURITYCONTEXTD

SERVICE

SECURITYCONTEXTB

APPLICATION

SECURITYCONTEXTA

interconnection

dbus, ws,bus1, tls,

...

network

Applications and services are running isolated one another by their smack security context

The communication between applications is controlled by policy (framework, firewall, gateway, OAuth, openid connect)

Access to service features is controlled by permission enforcement mechanism (cynara, OAuth)

Services are like applications


Mechanisms of security

● Mandatory Access Control with SMACK– Simple Mandatory Access Control Kernel– Strong isolation of kernel objects (files, sockets)

● Network firewall and filtering– Using netherd and netfilter

● Permission database cynara– Filtering permission– User consent mechanism

● User credential management– Oauth and OpenID Connect


Global view of security

LINUX KERNEL

PBACPermission Based

Access Control

Access Controlprovides

operations tocontrol accesses

+has_access()

MACMandatory Access

Control

DACDiscretionary

Access Control

SMACKSimple Mandatory

Access ControlKernel

CYNARAACL

Standard LinuxAccess Control

NSBACNameSpace Based

Access Control(containers)


Mechanisms of security

Protected Service

LINUX KERNEL

Legitimate application BlackHat application

System resource

The permission database

Cynara helps to protect services

Smack linux security module helps to protect

system resources

DENIED

DENIED

GRANTED

GRANTED


Permission checking

: SOLUTION : SERVICE

CONNECT

INVOKE METHOD

SIGNAL EVENT

return from INVOKE

Subject to permission to connect to the service

Subject to permission to invoke the METHOD of the service

Subject to permission to receive EVENT of the service

: CLIENT


Permission and composition of services

: SOLUTION X : SERVICE Y : SERVICE<<depends>> <<depends>>

Policy for Y is: requires permission P

About permission P, the policy for X is either: - P is required by transitivity - P is a hidden requirement of X

AGL framework takes care of composition of permissions. Under control of strict policy, it allows some services to run with the context of their clients, behaving as their client.

: CLIENT


Links

● Doc: http://docs.automotivelinux.org/● Wiki: https://wiki.automotivelinux.org/● More: https://iot.bzh/en/publications

http://docs.automotivelinux.org/

https://wiki.automotivelinux.org/

https://iot.bzh/en/publications


Overview of LSM SMACK


Short overview

● The author of Smack is mainly Casey Schaufler.● In Linux since kernel 2 6 25 – 17 April 2008 – as a

LSM (Linux Security Module)● Use extended file attributes to store data related to

files (like SELinux).● Controlled via a filesystem interface: smackfs.● Controls accesses of processes to files, IPC, sockets

and processes (ptrace, signals, ...).● Controls CIPSO labelled IPV4 packets● Integrated in systemd


The Smack rules

● Smack's rules have 3 items:– the subject's label– the object's label– the access

System User rwx

This rule tells to allow read, write and execute access to objects labeled User

for the processes labeled System.

What are labels? What are subjects? What are objects? How to set?

Simple !!!


The Smack vocabulary● Labels are just text (of valid ASCII characters) without any

special meaning: they are compared to equality (case sensitive: a≠A).

● Subjects are running processes: any running process has a smack label.

● Objects are files, IPC, sockets, processes.● The label of a running process is called its security

context.– Commands id, ps (option -Z or -M), ls (option -Z) are prompting

contexts processes and files.● The grantables access modes are: read (r), write (w),

execute (x), append (a), lock (l), transmute (t), bringup (b).


Setting Smack

How to set context? You can't! Except if you have the capability CAP_MAC_ADMIN.

# chsmack --access label file# echo -n label > /proc/$$/attr/current

# echo “subject object rwt” > /sys/fs/smackfs/load-self2# echo “subject object rwt” > /sys/fs/smackfs/load2

# echo “subject object rwt” | smackload

How to set rules? You can only reduce accesses for the current thread (inherited by cloning). But if you have the capability CAP_MAC_ADMIN, you can change all rules.


Evolutions of Smack

● The author of Smack is mainly Casey Schaufler.● In Linux since kernel 2 6 25 – 17 April 2008 – as a LSM (Linux

Security Module)● Evoluting since this first days.– Lock access mode (kernel 3.13)– Support for multi-rule write to load2 and change-rule (kernel 3.12)– Maximum value for CIPSO category change from 63 to 184 (kernel

3.12)– Longer Smack labels (24->255) and recursive transmute (kernel 3,5)– Transmute access mode (kernel 2.6.38)– Bringup mode– Netlabel filtering


Smack links

● Kernel doc: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Smack.html

● User space tools: https://github.com/smack-team/smack

●

https://www.kernel.org/doc/html/latest/admin-guide/LSM/Smack.html

https://www.kernel.org/doc/html/latest/admin-guide/LSM/Smack.html

https://github.com/smack-team/smack


Overview of CYNARA

permission database


cynara

● Cynara is a permission database● Cynara was introduced in 2014 by Samsung for

Tizen’s management of permissions– It was a response to the insane growth of smack rules

● Was introduced as an alternative to Polkit that was to slow

● This defines Tizen 3 versus previous Tizens● The main promoter and contributor is Samsung

Poland


The cynara rules

client session user permission

DENIED

GRANTED

OTHER (ASK, ...)

● The client is the requesting process identified by its Smack label● The session is supposed to identify the one session of the client● The user is the requesting user as identified by DAC● The permission is the permission that is tested

The 4-uple of values is checked

client, session, user and permission are text strings


cynara

low-can

cynara

HVAC The application HVAC runs with security label User::App::HVAC

Request cynara authorisation for User::App::HVAC PID UID PERMor if known User::App::HVAC SESSION-ID USER-ID PERM

The low-can service get the credentials of its client usinggetsockopt (SO_PEERCRED & SO_PEERSEC)

Request issued over UNIX Domain Socket

The server cynara checks whether a rule allows the request

Issue with NAND memory (limited write cycle) => specific optimizations

cache

Caching is possible to avoid request

(getsockopt is a C function)


cynara

...

cynara

agent

For some queries, the server cynara may ask an “agent” to give or not the authorization

agentagentagent

Example 1An agent can ask the user

Session manager

Example 2An agent can ask the session manager

The application The application HVACHVAC requires permission to change requires permission to change temperature.temperature.

Do you accept?Do you accept?

Yes foreverYes forever Yes nowYes now Not nowNot now NeverNever

A t t e n t i o nA t t e n t i o n


Cynara, comparison


Cynara, comparison

low-can

cynara

HVAC

cache

agent


Integration with DBus

● Samsung integrated cynara in Dbus. AGL use a patched version of DBUS (1.10.20 for AGL and 1.10.6 for tizen where current development is 1.13.6)– Includes asynchronous cynara checks– Will not enter upstream

● Integration in Dbus configuration files


Cynara links

● Introduction: https://wiki.tizen.org/Security:Cynara

● Github: https://github.com/Samsung/cynara● AGL version:

https://git.automotivelinux.org/AGL/meta-agl/tree/meta-security/recipes-security/cynara

● DBUS AGL version: https://git.automotivelinux.org/AGL/meta-agl/tree/meta-security/recipes-core/dbus-cynara

https://wiki.tizen.org/Security:Cynara

https://github.com/Samsung/cynara



https://git.automotivelinux.org/AGL/meta-agl/tree/meta-security/recipes-core/dbus-cynara

https://git.automotivelinux.org/AGL/meta-agl/tree/meta-security/recipes-core/dbus-cynara


Overview of AGL binder


Connecting micro-services

SERV

C

SERV

D

SERV

B

APP

A

● The connection between micro-services (and/or applications) is a detail that must be abstract to developers

● The framework knows how to connect applications and services

● Common programming model● Its name: afb-daemon


Programming model

monitor/get({“verbosity”: “monitor”})

Example: a call to get the verbosity level of API monitor

The api (or service)

The verb (or method) of the api

The request arguments is any JSON value

Example: curl invocation

$ curl -H ‘x-afb-token: HELLO’ \ localhost:1056/api/monitor/get?verbosity=monitor

Example: javascript invocation

afb.call(‘monitor/get’, {‘verbosity’: ‘monitor’}).then(gotapis);

Example: C binding invocation

wrap_json_pack(&req, “{ss}”, “verbosity”, “monitor”);afb_api_call(myapi, “monitor”, “get”, req, gotpis, NULL);

The reply is a JSON value

{ "verbosity": { "monitor":"info" }}


Programming model

● Advantages:– Using HTTP(s) and WS(s), the model crosses

firewalls– JSON data as argument or result introduce flexibility,

reliable portability and wide language binding– Agnostic about programming language

● Drawbacks:– Need for agreement on names of API– JSON (de)serialisation


Use case of the binder

cloudAPPLI SERVICE

BINDERA

BINDER

BAPPLI

BINDERC

BINDING

BINDERD

BINDING

Connected carMaster ECU

Other ECU

HTTPS+WSS/TCP HTTPS+WSS/TCP

WS/UDS

WSS/TCP

WS: WebSocketWSS: WS SecuredUDS: Unix Domain Socket


Binder vocabulary

● Binder: the process afb-daemon● Binding: a binary loaded by the binder that

implements one or more apis● Api: a set of verbs belonging to the same

name and implemented by only one binding● Verb: A callable endpoint, accept arguments,

return result, can be protected● Transparency or “shadow api”: fact that a

remote api is accessed like a local api


Feature of the AGL binder

● Connection of services and applications together (UDS, WS/UDS, WS/TCP, HTTP, linked)

● High level flexible RPC mechanism (hide connections)● Framework for event signaling● Security and permissions facilities (Smack + cynara)● HTTP server managing OPA and WebSockets● Binary implementation of services (aka “binding”)● Management of client sessions and contexts● Debugging, monitoring and supervision

RPC: Remote Procedure CallOPA: One Page Application


Protection of binder

● Connections can require a secret token● Execution of verbs of APIs can be protected– By permissions– By Level Of Assurance– By secret token

● Binder executes cynara checks● Binder controls internal execution, recovering from

failure in bindings● Automatic reconnection after server failures


Binder/Binding model●Binder–Container process

●Loads bindings (binaries currently but also possibly scripts if needed in future -js?-)

–Transport●Makes the transport abstract–Security–Standardized high level Sync/Async API–Standardized high level event model–Expose API through HTTP or WebSocket

● Protected by token●Binding–One or more API published through binder–Provided as:

● A native library weakly coupled (threading allowed)● A stub to a remote service

APPLICATION

BINDERafb-daemon

API Z

BINDERafb-daemon API Z

A

B

API X

API Y

Application and its binder runs the same security context

This binder implements two APIs: X and Y

This API is remote or imported

This binding implements only one API: Z

Implicit API/WS RPC

The binder exports the API Z

Explicit HTTP+WS link


Binder’s connections

● Binders accept 2 kind of incoming connections– Common HTTP+WS: this connection is the

common one (HTTP and/or WebSocket).● It acts as an HTTP server that accept upgrade to a

websocket for it api “pod”.● It exports all the API known by the binder● It manages sessions and tokens

– Specific API/WS: this connection is specific to an API (API over special WebSocket).

● Only one API● Doesn’t manage session or tokens


Connection of apis: API/WS

● The binder connects apis using point to point connections

● Compared to a bus, advantages are:– less contention

(pressure),– no mediator (security and

efficiency)

BINDERafb-daemon

API X

API Y

API Z

BINDERafb-daemon

API Z

API Y

BINDERafb-daemon

API Y


Libafbwsc & afb-client-demo

● The binder provides a client library to connect to binders either by their WS/HTTP pod or by their API/WS pod

● Some component of AGL use that library● A sample program demonstrates the use of

that library: afb-client-demo. It can be used to connect to binders during development.

● Still need a true documentation.


Use of binder

● Services gain high benefits to be integrated by binders, they get for free:– High level programming model with events– Connectivity managed– Security enforced

● Applications have the choice to either– Connect to a binder that is connected to service– Connect directly to the services it uses through

libafbwsc but in this case integration with the whole system may encounter glitches


UML view

: APPLICATION

: BINDER

: BINDING

: BINDING

: BINDING

: SERVICE

HTTP WebSocket

: BINDER

: BINDING

This link can be either DBus or UDS or WebSocket (on LAN or WAN)

Native link to services is not forbiden. A library allows to connect to Binder's services

A service can be implemented on top of binder's framework

security context APPLICATION

security context SERVICE


Monitoring


Supervision

● Monitor allows a client to debug and introspect itself

● Supervision is the extension that allows to inspect all binders, APIs and sessions

● Binders connect to the supervisor

● Access to supervisor are restricted

● Capabilities of supervisor are reduced on cars

BINDER

BINDER

BIN

DE

R

BIN

DE

R

BIN

DE

R

BIN

DE

R

BINDER

SUPERVISOR


Binder links

● Git on AGL: https://git.automotivelinux.org/src/app-framework-binder/

● Doc on AGL: http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-binder/afb-overview.html

https://git.automotivelinux.org/src/app-framework-binder/

https://git.automotivelinux.org/src/app-framework-binder/

http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-binder/afb-overview.html




Overview of

bindings and APIs


What are bindings?

● Generally one binding implement one API– It exports a set of verbs that can be called

● Bindings are loaded by the binder at start● Bindings receive request for verbs and should reply to it● Bindings can call verbs of other APIs for themselves or

for their client● Bindings are not linked to the binder, it can be executed

in other context or other binders● Currently bindings are binary libraries written in C/C++


Binding and APIs

● Bindings version 3 available since Funky Flounder are able to define 0, 1 or many APIs:– 0: No public interface, useful to create in binder

applications– 1: The standard case, static declaration preferred– 2+: This rare case is implemented by the controller

and used by 4A (AGL Advanced Audio Architecture)● New APIs can be created at any time (if

needed)


Link to OpenAPI

● OpenAPI is a linux foundation effort intended to standardizing on how REST APIs are described

● APIs can be described using a subset of OpenAPI v3 specification

● A generator can produce the skeleton of a binding based on its openAPI description

● The binder produce an openAPI compatible description of its API through call monitor/get({“api”:true})

● This is useful if you use swagger or compatible tool


The 3 main states

● The binder defines 3 main steps that the binding must respect and conform:– PREINIT: The binder discovers the bindings and loads it.

● No call to APIs is possible.● Can declare new APIs● Can explicit their class dependencies (provide/require)

– INIT: All the bindings are loaded, the binder call the initialization function (if any) of all API.

● Calls other APIs is possible● Can explicit their API dependencies (require)

– RUNNING: All initialization successful


Weak dependency

● Bindings are not linked to any binder library● Bindings receive the binder entry points like virtual function

table of C++● Bindings declare the version of the binder API it uses● Advantages:– Binder can adapt to the version of the binding– A same binding binary can be used by the binder or by programs

implementing binder interfaces

: BINDING : BINDER

binding's interface

binder's interface

: BINDING SOME APPLICATION

binding's interface

binder's interface


Example: hello world

1 #define AFB_BINDING_VERSION 3 2 #include <afb/afb-binding.h> 3 4 void hello(afb_req_t req) 5 { 6 AFB_REQ_DEBUG(req, "hello world"); 7 afb_req_reply(req, NULL, NULL, "hello world"); 8 } 9 10 const afb_verb_t verbs[] = { 11 { .verb="hello", .callback=hello }, 12 { .verb=NULL } 13 }; 14 15 const afb_binding_t afbBindingExport = { 16 .api = "tuto-1", 17 .verbs = verbs 18 };

static inlinevoid afb_req_reply(

afb_req_t *req,json_object *obj,const char *error,const char *info)

{req->itf->reply(req,

obj, error, info);}


Managing events

● APIs can create events by name– These are in fact handles to push events– Ex: the api telephony creates an event incomingCall

that is finally named event telephony/incomingCall

● APIs can push data for an event– Pushing means send the data tagged by the event name

to all listeners● APIs control how its clients subscribe to its events by

adding or removing it to the list of listeners● APIs can also listen for events


Example: event knock

1 afb_event_t evt_knock; 2 3 void knock(afb_req_t req) 4 { 5 afb_event_push(evt_knock, json_object_get(afb_req_json(req))); 6 afb_req_reply(req, NULL, NULL, NULL); 7 } 8 9 void listen(afb_req_t req) 10 { 11 if (json_object_get_boolean(afb_req_json(req))) 12 afb_req_subscribe(req, evt_knock); 13 else 14 afb_req_unsubscribe(req, evt_knock); 15 afb_req_reply(req, NULL, NULL, NULL); 16 } 17 18 void init(afb_api_t api) 19 { 20 evt_knock = afb_api_make_event(api, "knock"); 21 }


Overview of

WidgetsWGT


AGL development model

core

system

user

AGL profile sourceyocto generates the

core image

yocto generatesthe SDK

Applicationsources

WGTAGL SDK

Compilewith SDK

widget

WGT


Packaging applications

Developer team

Configuration fileconfig.xml

1. Developer team produces the application or service

2. Developer team describes its

product and its requirements

WGT


Security manifest: config.xml<?xml version="1.0" encoding="UTF-8"?><widget xmlns="http://www.w3.org/ns/widgets" id="org.openstreetmap.agl.pushviews" version="1.0.1"> <name>Push street views</name> <icon src="pushviews.png"/> <content src="index.html" type="text/html"/> <description>Pushes camera views to openstreetmap</description> <author>Open Street Map</author> <license>GPL</license> <feature name="urn:AGL:widget:required-api"> <param name="gps" value="ws" /> <param name="sensors" value="ws" /> <param name="camera" value="ws" /> <param name="pushviews:https://agl.openstreetmap.org/cloud/pushviews" value="cloud" /> </feature>…

WGT


Security manifest: config.xml

… <feature name="urn:AGL:widget:required-permission"> <param name="urn:AGL:permission:gps:public:read" value="required" /> <param name="urn:AGL:permission:sensors:public:read" value="required" /> <param name="urn:AGL:permission:camera:public:take:front" value="required" /> <param name="urn:AGL:permission:camera:public:take:rear" value="optional" /> </feature></widget>

WGT



Developer team

signed content

3. Developer team signs its product

WGT



signed content

Authority 1Authority 2

4. Authorities sign the product

WGT

That authority adds a key that will unlock special permissions



signed content

WGTWGT

packaged content

5. zip the product, its config and its signatures

WGT



signed content

WGTWGT

packaged content

config.xml

This signature opens permissions to the widget

WGT


Preferred structure of widgets

/

bin

lib

etc

lang

htdocs

en

jp

libexec

Native executables

Local libraries of executables (RPATH)

Bindings

Configuration files

...

Internationalization

index.html

...

config.xml

Served HTTP files

author.sig

...

Manifest files


links

● Widgets are defined by W3C: https://www.w3.org/TR/widgets/

● How they are signed is also defined by W3C: https://www.w3.org/TR/widgets-digsig/

● Implementation in AGL: https://git.automotivelinux.org/src/app-framework-main/

WGTWGT

https://www.w3.org/TR/widgets/

https://www.w3.org/TR/widgets-digsig/

https://git.automotivelinux.org/src/app-framework-main/



Overview of AGL

framework


History of the framework

Tizen 3

Ostro

AGL

June

2015

Marc

h 2015

Nov. 2015

First tizen 3 security

release

AGL spec 1.0 may 28th

Dec. 2

016

Integration to AGL

Start of refiting the framework

Introduction of the binder

synchronization

Marc

h 2017

Oct

. 2017

Integration to systemD

Integration to systemD with users


Cryptographic check of permission

● PKI model for signing authority● Public keys distribution● Use cryptography to compute the maximal

set of permission for an installed app● Records and check publisher and owner

certificates● Link file digests with IMA

public

partner

platform

system

Any Tiers Authorized Tiers Confident Tiers Manufacturer

Can't use sensitive features

Can access some sensitive features

Can access many sensitive features

Can access ALL features

optional


Definition of permissions

urn:AGL:permission:<api>:<level>:<hierarchical-name>

The API providing the permission. If empty (or

starting with @) then it is a transverse permission

not linked to an API.

One of the values:— system— platform— partner— publisher— owner— public

Colon separated names possibly defining hierarchies of permissions

Cryptography protection

Examples:● urn:AGL:permission::public:no-htdocs● urn:AGL:permission:afm:system:widget:install


Figure of the framework

AGL framework

WGT

WGT

Security Context

DB of apps=

Widget’s files + systemd units

systemd

service

APPLICATION

or


Figure of the framework

● Installation & uninstallation:– Manages right: smack + cynara + groups– Isolate

● Managing processes with systemd– Natural integration with boot sequence– Socket activation of services– Integration of cgroups and many other advanced

topics for free


config.xml

Integration with systemd

/etc/afm/afm-unit.conf

WGT

WGT

json

Mustacheengine

Unitsdescription

*.service *.socket ...

temporarydata

Unit installer


Internal widget config

<feature name="urn:AGL:widget:required-permission"> <param name="urn:AGL:permission:real-time" value="required" /> <param name="urn:AGL:permission:syscall:*" value="required" /> </feature>

"required-permission":{ "urn:AGL:permission:real-time":{ "name":"urn:AGL:permission:real-time", "value":"required" }, "urn:AGL:permission:syscall:*":{ "name":"urn:AGL:permission:syscall:*", "value":"required" }}

EXTRACT OF CONFIG.XML

INTERNAL JSON

Internal transformduring installation


Mustache templating

Hello {{name}}You have just won {{value}} dollars!{{#in_ca}}Well, {{taxed_value}} dollars, after taxes.{{/in_ca}}

Hello ChrisYou have just won 10000 dollars!Well, 6000.0 dollars, after taxes.

{ "name": "Chris", "value": 10000, "taxed_value": 10000 - (10000 * 0.4), "in_ca": true}

TEMPLATE DATA

PRODUCT

Details: https://mustache.github.io/https://gitlab.com/jobol/mustach

https://mustache.github.io/

https://gitlab.com/jobol/mustach


Example of afm-unit.conf

[Service]SmackProcessLabel=User::App::{{:id}}User=%i

CapabilityBoundingSet=AmbientCapabilities=

Slice=user-unlimited-%i.slice

{{#required-permission}} {{#urn:AGL:permission::public:display}} SupplementaryGroups=display {{/urn:AGL:permission::public:display}}{{/required-permission}}

Conditionnal group

UID of the useris the parameter

Setting of SMACK


Security Context

afb-daemon

Internal daemons

afm-system-daemon

Bindings

application

systemd

afm-user-daemon(legacy)

dbus

ws-client ws-client

USER LAND

SYSTEM LAND

afm-util

transitionnal

transitionnal


links

● Repo: https://git.automotivelinux.org/src/app-framework-main/

● Doc: http://docs.automotivelinux.org/docs/apis_services/en/dev/

● Localuser: https://github.com/iotbzh/nss-localuser



http://docs.automotivelinux.org/docs/apis_services/en/dev/

http://docs.automotivelinux.org/docs/apis_services/en/dev/

https://github.com/iotbzh/nss-localuser


Overview of user

management


User identity handling

● Default users exist: agl-driver and agl-passenger● Existing several ways of authenticating users– Key RF– Phone– Gesture– ...

● Provide dynamic allocation of uids for authenticated users● Use uids to ensure privacy of users and Smack for privacy

of applications● Link identity with the Oauth2 service to allow federation


Identity workflow

PAM activation

✔ Plugable Authentication Module✔ Standard✔ Highly configurable✔ Modular design

✔ Face recognition✔ Voice identification✔ Password

1. initiate authentication

2. start user session

User identity service

USER SESSION

Cloudidentity

User services

User applications3. sync


Identity service

User identity service

USER SESSION

Cloudidentity

User services

User applications

Userdata

● Manage user data● By application● Globally

● Manage synchronisation and caching● Provide OpenId negociation


Launching application

USER SESSION

afm-system-daemon systemd

Home screen User applications

UID of the clientis the parameter


Overview of AGL

anywhere for anyone


Acces control by token

● The application framework (APPFW) launches applications, services and binders. It allocates security tokens.

● When a client connects to its binder, it presents its security token.

● The binder queries the APPFW to check whether the security token is valid or not.

● The security token management could be delegated by the APPFW to a specialized service (design).

● Tokens should include:– Expiration– Credentials– Abstract identity


Local access

BINDER23

AGL domain (CAR) LOCAL“HOME SCREEN”

AGLAPPFW

APP23

⑤

①②

③

④

(1) Ask to launch APP 23(2) Launch APP 23(3) Ask its token (check of PID, SMACK, UID)(4) Connect to the binder with its token(5) Check token validity


Remote application

AGLBINDER

CLIENTBROWSER

APPLICATION

HTTPSWSS(tcp) tcp

uds

REVERSEPROXY

AGL domain (CAR)internet

Remote client can run on any OS: MAC OS, Windows, Android, Linux, ...


Remote access

BINDER23

CLIENTBROWSER

APP 23

REVERSEPROXY

AGL domain (CAR)internet REMOTE“HOME”CLIENT

BROWSER“HOME”

AGLAPPFW

④

②

③

①

(1) Ask to launch APP 23(2) Returns the URL of the BINDER for APP 23 and its token (in the URI?)(3) Connect to the binder with its token(4) Check token validity

①


With redirect

BINDER23

CLIENTBROWSER

APP 23

REVERSEPROXY

AGL domain (CAR)internet

AGLAPPFW

④ ②

③

①

(1) Connect to the binder with invalid token(2) Check token validity(3) Return redirect(4) Redirected query (sequel depend on policies)


Examples of AGL works


Pure HTML5 application

internetWeb Browser

BINDER

A

HTTPS+WSS/TCP

Awebruntime

(local)

● Any web browser, local or remote access the binder

● The binder acts as a web server OPA compliant

● The binder allows connection to AGL services

● The file AFB.js implement a simple connection to AGL APIs in javascript

Same security context

Data of the application

Access to services

OPA: One Page Application


Using AFB.js

1 var loc = document.location; 2 var args = new URLSearchParams(loc.search.substring(1)); 3 var afb = new AFB({ 4 host: loc.hostname + ':' + loc.port, 5 token: args.get("x-afb-token") || args.get("token") || "HELLO" 6 }); 7 var ws = new afb.ws(onopen, onabort); 8 9 function onopen() {10 ws.onclose = onabort;11 ws.onevent("*", onevent);12 ws.call("api/verb", { arg1: true, arg2: 'data' }).then(13 onsuccess, onerror);14 }


HTML5 application extended

Web Browser

A

HTTPS+WSS/TCP

Awebruntime

(local)

● The application includes a binding– Binary acceleration– Confidential code– Access to hardware

● The API(s) of the binding aren’t exported

● Only the application access the binding API

Access to servicesBINDERAPI


Using a binding

<?xml version="1.0" encoding="UTF-8"?><widget xmlns="http://www.w3.org/ns/widgets" id="exthtml5" version="1.0"> <name>Extended HTML5</name> <icon src="icon.png"/> <description>Example of application with binding</description> <author>me</author> <license>MIT</license> <content src="index.html" type="text/html"/> <feature name="urn:AGL:widget:required-binding"> <param name="libexec/binding-exthtml5.so" value="local" /> </feature></widget>


General service

● Exporting an API is essential to building a system

● The exported API can be protected by permissions

S

Access to other

services

BINDER API

Exported API

Data of the service


Native application

BINDER

ANative

● Any web browser, local or remote access the binder

● The binder acts as a web server OPA compliant

● The binder allows connection to AGL services

● The file AFB.js implement a simple connection to AGL APIs in javascript

Access to services

HTTP+WS/TCP


links

● AFB.js: https://git.automotivelinux.org/src/app-framework-binder/tree/test/AFB.js

● QafbWebsocketClient: https://git.automotivelinux.org/apps/app-afb-helpers-submodule/

●

https://git.automotivelinux.org/src/app-framework-binder/tree/test/AFB.js

https://git.automotivelinux.org/src/app-framework-binder/tree/test/AFB.js

https://git.automotivelinux.org/apps/app-afb-helpers-submodule/

https://git.automotivelinux.org/apps/app-afb-helpers-submodule/


Managing Level Of

Assurance


LOA within bindings

● The binder provide by client and by API a value called LOA (for Level Of Assurance) (from 0 to 7)

● Standard meaning of LOA are:– Level of Assurance 1: Little or no confidence in the asserted identity’s validity. – Level of Assurance 2: Some confidence in the asserted identity’s validity. – Level of Assurance 3: High confidence in the asserted identity’s validity. – Level of Assurance 4: Very high confidence in the asserted identity’s validity.

● The binding implementation manages that value using the verb afb_req_session_set_LOA

● The LOA can be checked as a requirement before an API’s verb is called

● Binding implementations are allowed to change the meaning of the LOA level for their own purpose


LOA example

AFB_SESSION_LOA_1

afb_auth_Permission

void login(afb_req_t *req) {

afb_req_session_set_LOA(req, 1);

afb_req_success(req, NULL, NULL);

}

afb_auth_t autlogin = { .type=afb_auth_Permission,

.text=”urn:AGL:permission:...” };

afb_verb_t verbs[] = { { .verb=”login”, .callback=login, .auth=&autlogin },

{ .verb=”action”, .callback=action,

.session=AFB_SESSION_LOA_1 }, { .verb=NULL }

};


Level of Assurance links

● https://sites.google.com/a/aniltj.org/ficam/home

● http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-binder/reference-v3/func-req.html#afbreqsessionsetloa

● http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-binder/reference-v3/types-and-globals.html#the-types-afbautht-and-afbauthtypet

●

https://sites.google.com/a/aniltj.org/ficam/home

https://sites.google.com/a/aniltj.org/ficam/home

http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-binder/reference-v3/func-req.html#afbreqsessionsetloa



http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-binder/reference-v3/types-and-globals.html#the-types-afbautht-and-afbauthtypet





Design philosophy

KEEP IT SIMPLE

and Flying !

Overview of AGL the FLOSS embedded secured OS based on linux · 2018-10-10 · ACL Standard Linux...

Documents

Transcript of Overview of AGL the FLOSS embedded secured OS based on linux · 2018-10-10 · ACL Standard Linux...