5 The Automotive Grade Linux platform is a Linux distribution with **AGL**
6 compliant applications and services. The platform includes the following
9 - Linux **BSP** configured for reference boards.
10 - Proprietary device drivers for common peripherals on reference boards.
11 - Application framework.
12 - Windows/layer management (graphics).
13 - Sound resource management.
14 - An atomic software update system (chapter Update).
15 - Building and debug tools (based on Yocto project).
20 ------------------- | --------------------------------
21 Platform-Abstract-1 | Create a graphics and sound part.
25 This part focuses on the AGL platform including all tools and techniques used to
26 upgrade the security and downgrade the danger. It must be possible to apply the
27 two fundamental principles written at the very beginning of the document. First
28 of all, security management must remain simple. You must also prohibit
29 everything by default, and then define a set of authorization rules. As cases to
32 - Implement a **MAC** for processes and files.
33 - Limit communication between applications (_SystemBus_ and _SystemD_ part).
34 - Prohibit all tools used during development mode (_Utilities_ and _Services_
36 - Manage user capabilities (_Users_ part).
37 - Manage application permissions and policies (_AGLFw_ part).
41 The tools and concepts used to meet these needs are only examples. Any other
42 tool that meets the need can be used.
46 In AGL, as in many other embedded systems, different security mechanisms settle
47 in the core layers to ensure isolation and data privacy. While the Mandatory
48 Access Control layer (**SMACK**) provides global security and isolation, other
49 mechanisms like **Cynara** are required to check application's permissions at
50 runtime. Applicative permissions (also called "_privileges_") may vary depending
51 on the user and the application being run: an application should have access to
52 a given service only if it is run by the proper user and if the appropriate
53 permissions are granted.
55 ## Discretionary Access Control
57 **D**iscretionary **A**ccess **C**ontrol (**DAC**) is the traditional Linux
58 method of separating users and groups from one another. In a shared environment
59 where multiple users have access to a computer or network, Unix IDs have offered
60 a way to contain access within privilege areas for individuals, or shared among
61 the group or system. The Android system took this one step further, assigning
62 new user IDs for each App. This was never the original intention of Linux UIDs,
63 but was able to provide Android’s initial security element: the ability to
66 Although AGL mentions use of **DAC** for security isolation, the weight of the
67 security responsibility lies in the **M**andatory **A**ccess **C**ontrol
68 (**MAC**) and **Cynara**. Furthermore, there are system services with unique
69 UIDs. however,the system does not go to the extreme of Android, where every
70 application has its own UID. All sandboxing (app isolation) in AGL is handled in
73 ## Mandatory Access Control
75 **M**andatory **A**ccess **C**ontrol (**MAC**) is an extension to **DAC**,
76 whereby extended attributes (xattr) are associated with the filesystem. In the
77 case of AGL, the smackfs filesystem allows files and directories to be
78 associated with a SMACK label, providing the ability of further discrimination
79 on access control. A SMACK label is a simple null terminated character string
80 with a maximum of 255 bytes. While it doesn’t offer the richness of an SELinux
81 label, which provides a user, role,type, and level, the simplicity of a single
82 value makes the overall design far less complex. There is arguably less chance
83 of the security author making mistakes in the policies set forth.
85 --------------------------------------------------------------------------------
89 ## Acronyms and Abbreviations
91 The following table lists the terms utilized within this part of the document.
93 Acronyms or Abbreviations | Description
94 ------------------------- | --------------------------------------------------------------
95 _ACL_ | **A**ccess **C**ontrol **L**ists
96 _alsa_ | **A**dvanced **L**inux **S**ound **A**rchitecture
97 _API_ | **A**pplication **P**rogramming **I**nterface
98 _AppFw_ | **App**lication **F**rame**w**ork
99 _BSP_ | **B**oard **S**upport **P**ackage
100 _Cap_ | **Cap**abilities
101 _DAC_ | **D**iscretionary **A**ccess **C**ontrol
102 _DDOS_ | **D**istributed **D**enial **O**f **S**ervice
103 _DOS_ | **D**enial **O**f **S**ervice
104 _IPC_ | **I**nter-**P**rocess **C**ommunication
105 _MAC_ | **M**andatory **A**ccess **C**ontrol
106 _PAM_ | **P**luggable **A**uthentication **M**odules
107 _SMACK_ | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel
109 # Mandatory Access Control
113 We decided to put the **MAC** protection on the platform part despite the fact
114 that it applies to the kernel too, since its use will be mainly at the platform
115 level (except floor part).
119 **M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the
120 Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL
121 uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol
122 **K**ernel (**SMACK**). This protection involves the creation of **SMACK**
123 labels as part of the extended attributes **SMACK** labels to the file extended
124 attributes. And a policy is also created to define the behaviour of each label.
126 The kernel access controls is based on these labels and this policy. If there is
127 no rule, no access will be granted and as a consequence, what is not explicitly
128 authorized is forbidden.
130 There are two types of **SMACK** labels:
132 - **Execution SMACK** (Attached to the process): Defines how files are
133 _accessed_ and _created_ by that process.
134 - **File Access SMACK** (Written to the extended attribute of the file): Defines
135 _which_ process can access the file.
137 By default a process executes with its File Access **SMACK** label unless an
138 Execution **SMACK** label is defined.
140 AGL's **SMACK** scheme is based on the _Tizen 3 Q2/2015_. It divides the System
141 into the following domains:
145 - Applications, Services and User.
147 See [AGL security framework
148 review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf)
150 Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf)
151 for more information.
153 --------------------------------------------------------------------------------
159 The _floor_ domain includes the base system services and any associated data and
160 libraries. This data remains unchanged at runtime. Writing to floor files or
161 directories is allowed only in development mode or during software installation
164 The following table details the _floor_ domain:
166 Label | Name | Execution **SMACK** | File Access **SMACK**
167 ----- | ----- | ------------------- | ---------------------------------------
168 `-` | Floor | `r-x` for all | Only kernel and internal kernel thread.
169 `^` | Hat | `---` for all | `rx` on all domains.
170 `*` | Star | `rwx` for all | None
174 - The Hat label is Only for privileged system services (currently only
175 systemd-journal). Useful for backup or virus scans. No file with this label
176 should exist except in the debug log.
178 - The Star label is used for device files or `/tmp` Access restriction managed
179 via **DAC**. Individual files remain protected by their **SMACK** label.
183 Domain | `Label` name | Recommendations
184 ------------------ | ------------ | -----------------------------------------------------------
185 Kernel-MAC-Floor-1 | `^` | Only for privileged system services.
186 Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC.
190 --------------------------------------------------------------------------------
196 The _system_ domain includes a reduced set of core system services of the OS and
197 any associated data. This data may change at runtime.
199 The following table details the _system_ domain:
201 Label | Name | Execution **SMACK** | File Access **SMACK**
202 ---------------- | --------- | ----------------------------------------------- | ---------------------
203 `System` | System | None | Privileged processes
204 `System::Run` | Run | `rwxatl` for User and System label | None
205 `System::Shared` | Shared | `rwxatl` for system domain `r-x` for User label | None
206 `System::Log` | Log | `rwa` for System label `xa` for user label | None
207 `System::Sub` | SubSystem | Subsystem Config files | SubSystem only
211 Domain | `Label` name | Recommendations
212 ------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------
213 Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute.
214 Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`.
215 Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege.
216 Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append.
217 Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem.
221 --------------------------------------------------------------------------------
225 ## Applications, Services and User
227 The _application_, _services_ and _user_ domain includes code that provides
228 services to the system and user, as well as any associated data. All code
229 running on this domain is under _Cynara_ control.
231 The following table details the _application_, _services_ and _user_ domain:
233 Label | Name | Execution **SMACK** | File Access **SMACK**
234 ------------------- | ------ | --------------------------------------------------------------------------- | ---------------------------
235 `User::Pkg::$AppID` | AppID | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App
236 `User::Home` | Home | `rwx-t` from System label `r-x-l` from App | None
237 `User::App-Shared` | Shared | `rwxat` from System and User domains label of $User | None
241 Domain | `Label` name | Recommendations
242 ------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------
243 Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode.
244 Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute.
245 Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user.
251 There are 4 major components to the system:
253 - The LSM kernel module.
254 - The `smackfs` filesystem.
255 - Basic utilities for policy management and checking.
256 - The policy/configuration data.
258 As with any mandatory access system, the policy management needs to be carefully
259 separated from the checking, as the management utilities can become a convenient
260 point of attack. Dynamic additions to the policy system need to be carefully
261 verified, as the ability to update the policies is often needed, but introduces
262 a possible threat. Finally, even if the policy management is well secured, the
263 policy checking and failure response to that checking is also of vital
264 importance to the smooth operation of the system.
266 While **MAC** is a certainly a step up in security when compared to DAC, there
267 are still many ways to compromise a SMACK-enabled Linux system. Some of these
270 - Disabling SMACK at invocation of the kernel (with command-line:
272 - Disabling SMACK in the kernel build and redeploying the kernel.
273 - Changing a SMACK attribute of a file or directory at install time.
274 - Tampering with a process with the CAP_MAC_ADMIN privilege.
275 - Setting/Re-setting the SMACK label of a file.
276 - Tampering with the default domains (i.e.
277 /etc/smack/accesses.d/default-access-domains).
278 - Disabling or tampering with the SMACK filesystem (i.e. /smackfs).
279 - Adding policies with `smackload` (adding the utility if not present).
280 - Changing labels with `chsmack` (adding the utility if not present).
284 `afm-system-daemon` is used to:
286 - Manage users and user sessions.
287 - Setup applications and services (_CGroups_, _namespaces_, autostart,
289 - Use of `libsystemd` for its programs (event management, **D-Bus** interface).
293 Domain | Object | Recommendations
294 ------------------ | -------------- | ------------------------------------
295 Platform-SystemD-1 | Security model | Use Namespaces for containerization.
296 Platform-SystemD-2 | Security model | Use CGroups to organise processes.
300 See [systemd integration and user
301 management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf) for
306 - Removal of one privileged process: **afm-user-daemon**
307 - Access and use of high level features:
310 - Management of users and integration of **PAM**.
311 - Dependency resolution to services.
312 - `Cgroups` and resource control.
313 - `Namespaces` containerization.
314 - Autostart of required API.
315 - Permissions and security settings.
316 - Network management.
322 Control Groups offer a lot of features, with the most useful ones you can
323 control: Memory usage, how much CPU time is allocated, how much device I/O is
324 allowed or which devices can be accessed. **SystemD** uses _CGroups_ to organise
325 processes (each service is a _CGroups_, and all processes started by that
326 service use that _CGroups_). By default, **SystemD** automatically creates a
327 hierarchy of slice, scope and service units to provide a unified structure for
328 the _CGroups_ tree. With the `systemctl` command, you can further modify this
329 structure by creating custom slices. Currently, in AGL, there are 2 slices
330 (**user.slice** and **system.slice**).
336 There are several ways of authenticating users (Key Radio Frequency, Phone,
337 Gesture, ...). Each authentication provides dynamic allocation of **uids** to
338 authenticated users. **Uids** is used to ensure privacy of users and **SMACK**
339 for applications privacy.
341 First, the user initiates authentication with **PAM** activation. **PAM**
342 Standard offers highly configurable authentication with modular design like face
343 recognition, Voice identification or with a password. Then users should access
344 identity services with services and applications.
348 D-Bus is a well-known **IPC** (Inter-Process Communication) protocol (and
349 daemon) that helps applications to talk to each other. The use of D-Bus is great
350 because it allows to implement discovery and signaling.
352 The D-Bus session is by default addressed by environment variable
353 `DBUS_SESSION_BUS_ADDRESS`. Using **systemd** variable
354 `DBUS_SESSION_BUS_ADDRESS` is automatically set for user sessions. D-Bus usage
355 is linked to permissions.
357 D-Bus has already had several [security
358 issues](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
359 (mostly **DoS** issues), to allow applications to keep talking to each other. It
360 is important to protect against this type of attack to keep the system more
366 Domain | Object | Recommendations
367 --------------- | -------------- | ------------------------------------
368 Platform-DBus-1 | Security model | Use D-Bus as IPC.
369 Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
373 # System services and daemons
378 ------------------- | -----------
379 Platform-Services-1 | SystemD ?
380 Platform-Services-2 | Secure daemon ?
386 - **connman**: An internet connection manager designed to be slim and to use as
387 few resources as possible. It is a fully modular system that can be extended,
388 through plug-ins, to support all kinds of wired or wireless technologies.
389 - **bluez** is a Bluetooth stack. Its goal is to program an implementation of
390 the Bluetooth wireless standards specifications. In addition to the basic
391 stack, the `bluez-utils` and `bluez-firmware` packages contain low level
392 utilities such as `dfutool` which can interrogate the Bluetooth adapter
393 chipset in order to determine whether its firmware can be upgraded.
394 - **gstreamer** is a pipeline-based multimedia framework. It can be used to
395 build a system that reads files in one format, processes them, and exports
396 them in another format.
397 - **alsa** is a software framework and part of the Linux kernel that provides an
398 **API** for sound card device drivers.
402 Domain | `Tool` name | _State_
403 -------------------- | ----------- | -------
404 Platform-Utilities-1 | `connman` | _Used_ as a connection manager.
405 Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager.
406 Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format.
407 Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers.
411 # Application framework/model (**AppFw**)
413 The AGL application framework consists of several inter-working parts:
415 - **SMACK**: The kernel level **LSM** (**L**inux **S**ecurity **M**odule) that
416 performs extended access control of the system.
417 - **Cynara**: the native gatekeeper daemon used for policy handling, updating to
418 the database and policy checking.
419 - Security Manager: a master service, through which all security events are
420 intended to take place.
421 - Several native application framework utilities: `afm-main-binding`,
422 `afm-user-daemon`, `afm-system-daemon`.
424 The application framework manages:
426 - The applications and services management: Installing, Uninstalling, Listing,
428 - The life cycle of applications: Start -> (Pause, Resume) -> Stop.
429 - Events and signals propagation.
430 - Privileges granting and checking.
431 - API for interaction with applications.
435 - The **security model** refers to the security model used to ensure security
436 and to the tools that are provided for implementing that model. It's an
437 implementation detail that should not impact the layers above the application
440 - The **security model** refers to how **DAC** (**D**iscretionary **A**ccess
441 **C**ontrol), **MAC** (Mandatory Access Control) and `Capabilities` are used
442 by the system to ensure security and privacy. It also includes features of
443 reporting using audit features and by managing logs and alerts.
447 The **AppFw** uses the security model to ensure the security and the privacy of
448 the applications that it manages. It must be compliant with the underlying
449 security model. But it should hide it to the applications.
453 Domain | Object | Recommendations
454 ---------------------- | -------------- | --------------------------------
455 Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model.
459 See [AGL AppFw Privileges
460 Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf)
461 and [AGL - Application Framework
462 Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf)
463 for more information.
467 The Security Manager communicates policy information to **Cynara**, which
468 retains information in its own database in the format of a text file with
469 comma-separated values (CSV). There are provisions to retain a copy of the CSV
470 text file when the file is being updated.
472 Runtime checking occurs through **Cynara**. Each application that is added to
473 the framework has its own instantiation of a SMACK context and D-bus bindings.
474 The afb_daemon and Binder form a web-service that is communicated to through
475 http or a websocket from the application-proper. This http or websocket
476 interface uses a standard unique web token for API communication.
478 ![Application Framework Flow](images/App-flow.png)
482 There's a need for another mechanism responsible for checking applicative
483 permissions: Currently in AGL, this task depends on a policy-checker service
486 - Stores complex policies in databases.
487 - "Soft" security (access is checked by the framework).
489 Cynara interact with **D-Bus** in order to deliver this information.
491 Cynara consists of several parts:
493 - Cynara: a daemon for controlling policies and responding to access control
495 - Database: a spot to hold policies.
496 - Libraries: several static and dynamic libraries for communicating with Cynara.
498 The daemon communicates to the libraries over Unix domain sockets. The database
499 storage format is a series of CSV-like files with an index file.
501 There are several ways that an attacker can manipulate policies of the Cynara
504 - Disable Cynara by killing the process.
505 - Tamper with the Cynara binary on-disk or in-memory.
506 - Corrupt the database controlled by Cynara.
507 - Tamper with the database controlled by Cynara.
508 - Highjack the communication between Cynara and the database.
510 The text-based database is the weakest part of the system and although there are
511 some consistency mechanisms in place (i.e. the backup guard), these mechanisms
512 are weak at best and can be countered by an attacker very easily.
516 Domain | Object | Recommendations
517 ----------------------- | ----------- | -------------------------------------
518 Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service.
526 - Are simple - for pair [application context, privilege] there is straight
527 answer (single Policy Type): [ALLOW / DENY / ...].
528 - No code is executed (no script).
529 - Can be easily cached and managed.
531 - Application context (describes id of the user and the application credentials)
534 - UID of the user that runs the application.
535 - **SMACK** label of application.
539 Policies are kept in buckets. Buckets are set of policies which have additional
540 a property of default answer, the default answer is yielded if no policy matches
541 searched key. Buckets have names which might be used in policies (for
546 The following attack vectors are not completely independent. While attackers may
547 have varying levels of access to an AGL system, experience has shown that a
548 typical attack can start with direct access to a system, find the
549 vulnerabilities, then proceed to automate the attack such that it can be invoked
550 from less accessible standpoint (e.g. remotely). Therefore, it is important to
551 assess all threat levels, and protect the system appropriately understanding
552 that direct access attacks are the door-way into remote attacks.
556 The local web server interface used for applications is the first point of
557 attack, as web service APIs are well understood and easily intercepted. The
558 local web server could potentially be exploited by redirecting web requests
559 through the local service and exploiting the APIs. While there is the use of a
560 security token on the web service API, this is weak textual matching at best.
561 This will not be difficult to spoof. It is well known that [API Keys do not
562 provide any real security](http://nordicapis.com/why-api-keys-are-not-enough/).
564 It is likely that the architectural inclusion of an http / web-service interface
565 provided the most flexibility for applications to be written natively or in
566 HTML5. However, this flexibility may trade-off with security concerns. For
567 example, if a native application were linked directly to the underlying
568 framework services, there would be fewer concerns over remote attacks coming
569 through the web-service interface.
571 Leaving the interface as designed, mitigations to attacks could include further
572 securing the interface layer with cryptographic protocols: e.g. encrypted
573 information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman).
575 ### User-level Native Attacks
577 - Modifying the CSV data-base
578 - Modifying the SQLite DB
579 - Tampering with the user-level binaries
580 - Tampering with the user daemons
581 - Spoofing the D-bus Interface
582 - Adding executables/libraries
584 With direct access to the device, there are many security concerns on the native
585 level. For example, as **Cynara** uses a text file data-base with
586 comma-separated values (CSV), an attacker could simply modify the data-base to
587 escalate privileges of an application. Once a single application has all the
588 privileges possible on the system, exploits can come through in this manner.
589 Similarly the SQLite database used by the Security Manager is not much different
590 than a simple text file. There are many tools available to add, remove, modify
591 entries in an SQLite data-base.
593 On the next level, a common point of attack is to modify binaries or daemons for
594 exploiting functionality. There are many Linux tools available to aid in this
595 regard, including: [IDA Pro](https://www.hex-rays.com/products/ida/index.shtml),
596 and [radare2](https://rada.re/r/). With the ability to modify binaries, an
597 attacker can do any number of activities including: removing calls to security
598 checks, redirecting control to bypass verification functionality, ignoring
599 security policy handling, escalating privileges, etc.
601 Additionally, another attack vector would be to spoof the D-bus interface. D-bus
602 is a message passing system built upon Inter-Process Communication (IPC), where
603 structured messages are passed based upon a protocol. The interface is generic
604 and well documented. Therefore, modifying or adding binaries/libraries to spoof
605 this interface is a relatively straight-forward process. Once the interface has
606 been spoofed, the attacker can issue any number of commands that lead into
607 control of low-level functionality.
609 Protecting a system from native attacks requires a methodical approach. First,
610 the system should reject processes that are not sanctioned to run.
611 Signature-level verification at installation time will help in this regard, but
612 run-time integrity verification is much better. Signatures need to originate
613 from authorized parties, which is discussed further in a later section on the
616 On the next level, executables should not be allowed to do things where they
617 have not been granted permission. DAC and SMACK policies can help in this
618 regard. On the other hand, there remain concerns with memory accesses, system
619 calls, and other process activity that may go undetected. For this reason, a
620 secure environment which monitors all activity can give indication of all
621 unauthorized activity on the system.
623 Finally, it is very difficult to catch attacks of direct tampering in a system.
624 These types of attacks require a defense-in-depth approach, where complementary
625 software protection and hardening techniques are needed. Tamper-resistance and
626 anti-reverse-engineering technologies include program
627 transformations/obfuscation, integrity verification, and white-box cryptography.
628 If applied in a mutually-dependent fashion and considering performance/security
629 tradeoffs, the approach can provide an effective barrier to direct attacks to
630 the system. Furthermore, the use of threat monitoring provides a valuable
631 telemetry/analytics capability and the ability to react and renew a system under
634 ### Root-level Native Attacks
636 - Tampering the system daemon
638 - Tampering the security manager
640 - Tampering the kernel
642 Once root-level access (i.e. su) has been achieved on the device, there are many
643 ways to compromise the system. The system daemon, **Cynara**, and the security
644 manager are vulnerable to tampering attacks. For example, an executable can be
645 modified in memory to jam a branch, jump to an address, or disregard a check.
646 This can be as simple as replacing a branch instruction with a NOP, changing a
647 memory value, or using a debugger (e.g. gdb, IDA) to change an instruction.
648 Tampering these executables would mean that policies can be ignored and
649 verification checks can be bypassed.
651 Without going so far as to tamper an executable, the **SMACK** system is also
652 vulnerable to attack. For example, if the kernel is stopped and restarted with
653 the *security=none* flag, then SMACK is not enabled. Furthermore, `systemd`
654 starts the loading of **SMACK** rules during start-up. If this start-up process
655 is interfered with, then **SMACK** will not run. Alternatively, new policies can
656 be added with `smackload` allowing unforeseen privileges to alternative
657 applications/executables.
659 Another intrusion on the kernel level is to rebuild the kernel (as it is
660 open-source) and replace it with a copy that has **SMACK** disabled, or even
661 just the **SMACK** filesystem (`smackfs`) disabled. Without the extended label
662 attributes, the **SMACK** system is disabled.
664 Root-level access to the device has ultimate power, where the entire system can
665 be compromised. More so, a system with this level access allows an attacker to
666 craft a simpler *point-attack* which can operate on a level requiring fewer
667 privileges (e.g. remote access, user-level access).
669 ## Vulnerable Resources
671 ### Resource: `afm-user-daemon`
673 The `afm-user-daemon` is in charge of handling applications on behalf of a user.
676 - Enumerate applications that the end user can run and keep this list available
678 - Start applications on behalf of the end user, set user running environment,
679 set user security context.
680 - List current runnable or running applications.
681 - Stop (aka pause), continue (aka resume), terminate a running instance of a
683 - Transfer requests for installation/uninstallation of applications to the
684 corresponding system daemon afm-system-daemon.
686 The `afm-user-daemon` launches applications. It builds a secure environment for
687 the application before starting it within that environment. Different kinds of
688 applications can be launched, based on a configuration file that describes how
689 to launch an application of a given kind within a given launching mode: local or
690 remote. Launching an application locally means that the application and its
691 binder are launched together. Launching an application remotely translates in
692 only launching the application binder.
694 The UI by itself has to be activated remotely by a request (i.e. HTML5
695 homescreen in a browser). Once launched, running instances of the application
696 receive a `runid` that identifies them. `afm-user-daemon` manages the list of
697 applications that it has launched. When owning the right permissions, a client
698 can get the list of running instances and details about a specific running
699 instance. It can also terminate, stop or continue a given application. If the
700 client owns the right permissions, `afm-user-daemon` delegates the task of
701 installing and uninstalling applications to `afm-system-daemon`.
703 `afm-user-daemon` is launched as a `systemd` service attached to a user session.
704 Normally, the service file is located at
705 /usr/lib/systemd/user/afm-user-daemon.service.
709 - Disable `afm-user-daemon`.
710 - Tamper with the `afm-user-daemon` configuration.
711 - /usr/lib/systemd/user/afm-user-daemon.service.
712 - Application(widget) config.xml file.
713 - /etc/afm/afm-launch.conf (launcher configuration).
715 - Escalate user privileges to gain more access with `afm-user-daemon`.
716 - Install malicious application (widget).
717 - Tamper with `afm-user-daemon` on disk or in memory.
719 ### Resource: `afm-system-daemon`
721 The `afm-system-daemon` is in charge of installing applications on the AGL
722 system. Its main tasks are:
724 - Install applications and setup security framework for newly installed
726 - Uninstall applications.
728 `afm-system-daemon` is launched as a `systemd` service attached to system.
729 Normally, the service file is located at
730 /lib/systemd/system/afm-systemdaemon.service.
734 - Disable `afm-system-daemon`.
735 - Tamper with the `afm-system-daemon` configuration.
736 - Tamper `afm-system-daemon` on disk or in memory.
738 ### Resource `afb-daemon`
740 `afb-binder` is in charge of serving resources and features through an HTTP
741 interface. `afb-daemon` is in charge of binding one instance of an application
742 to the AGL framework and AGL system. The application and its companion binder
743 run in a secured and isolated environment set for them. Applications are
744 intended to access to AGL system through the binder. `afb-daemon` binders serve
745 files through HTTP protocol and offers developers the capability to expose
746 application API methods through HTTP or WebSocket protocol.
748 Binder bindings are used to add APIs to `afb-daemon`. The user can write a
749 binding for `afb-daemon`. The binder `afb-daemon` serves multiple purposes:
751 1. It acts as a gateway for the application to access the system.
752 2. It acts as an HTTP server for serving files to HTML5 applications.
753 3. It allows HTML5 applications to have native extensions subject to security
754 enforcement for accessing hardware resources or for speeding up parts of
759 - Break from isolation.
760 - Disable `afb-daemon`.
761 - Tamper `afb-demon` on disk or in memory.
762 - Tamper **capabilities** by creating/installing custom bindings for
767 - **busybox**: Software that provides several stripped-down Unix tools in a
768 single executable file. Of course, it will be necessary to use a "production"
769 version of **busybox** in order to avoid all the tools useful only in
774 Domain | `Tool` name | _State_
775 -------------------- | ----------- | ----------------------------------------------------------------------
776 Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools.
780 ## Functionalities to exclude in production mode
782 In production mode, a number of tools must be disabled to prevent an attacker
783 from finding logs for example. This is useful to limit the visible surface and
784 thus complicate the fault finding process. The tools used only in development
785 mode are marked by an '**agl-devel**' feature. When building in production mode,
786 these tools will not be compiled.
790 Domain | `Utility` name and normal `path` | _State_
791 --------------------- | ---------------------------------------------------- | ----------
792 Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_
793 Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_
794 Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_
795 Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_
796 Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_
797 Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_
798 Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_
799 Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_
800 Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_
801 Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_
802 Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_
803 Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_
804 Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_
805 Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_
806 Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_
807 Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_
808 Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_
809 Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_
810 Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_
811 Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_
812 Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_
813 Platform-Utilities-22 | `SSH` | _Disabled_
814 Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_
815 Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_
816 Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_
817 Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_
818 Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_
819 Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_
820 Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_
821 Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_
822 Platform-Utilities-31 | `awk` (busybox) | _Enabled_
823 Platform-Utilities-32 | `cut` (busybox) | _Enabled_
824 Platform-Utilities-33 | `df` (busybox) | _Enabled_
825 Platform-Utilities-34 | `echo` (busybox) | _Enabled_
826 Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_
827 Platform-Utilities-36 | `grep` (busybox) | _Enabled_
828 Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_
829 Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_
830 Platform-Utilities-39 | `printf` (busybox) | _Enabled_
831 Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_
832 Platform-Utilities-41 | `tail` (busybox) | _Enabled_
833 Platform-Utilities-42 | `tee` (busybox) | _Enabled_
834 Platform-Utilities-43 | `test` (busybox) | _Enabled_
838 The _Enabled_ Unix/Linux utilities above shall be permitted as they are often
839 used in the start-up scripts and for USB logging. If any of these utilities are
840 not required by the device then those should be removed.
846 The user policy can group users by function within the car. For example, we can
847 consider a driver and his passengers. Each user is assigned to a single group to
848 simplify the management of space security.
852 The main applications, those that provide the principal functionality of the
853 embedded device, should not execute with root identity or any capability.
855 If the main application is allowed to execute at any capability, then the entire
856 system is at the mercy of the said application's good behaviour. Problems arise
857 when an application is compromised and able to execute commands which could
858 consistently and persistently compromise the system by implanting rogue
861 It is suggested that the middleware and the UI should run in a context on a user
862 with no capability and all persistent resources should be maintained without any
865 One way to ensure this is by implementing a server-client paradigm. Services
866 provided by the system's drivers can be shared this way. The other advantage of
867 this approach is that multiple applications can share the same resources at the
872 Domain | Object | Recommendations
873 --------------------- | ---------------- | -----------------------------------------------------
874 Platform-Users-root-1 | Main application | Should not execute as root.
875 Platform-Users-root-2 | UI | Should run in a context on a user with no capability.
879 Root access should not be allowed for the following utilities:
883 Domain | `Utility` name | _State_
884 --------------------- | -------------- | -------------
885 Platform-Users-root-3 | `login` | _Not allowed_
886 Platform-Users-root-4 | `su` | _Not allowed_
887 Platform-Users-root-5 | `ssh` | _Not allowed_
888 Platform-Users-root-6 | `scp` | _Not allowed_
889 Platform-Users-root-7 | `sftp` | _Not allowed_
893 Root access should not be allowed for the console device. The development
894 environment should allow users to login with pre-created user accounts.
896 Switching to elevated privileges shall be allowed in the development environment
899 --------------------------------------------------------------------------------
908 ----------------------------- | ------------------------
909 Platform-Users-Capabilities-1 | Kernel or Platform-user?
910 Platform-Users-Capabilities-2 | Add config note.
914 The goal is to restrict functionality that will not be useful in **AGL**. They
915 are integrated into the **LSM**. Each privileged transaction is associated with
916 a capability. These capabilities are divided into three groups:
918 - e: Effective: This means the capability is “activated”.
919 - p: Permitted: This means the capability can be used/is allowed.
920 - i: Inherited: The capability is kept by child/subprocesses upon execve() for