{% set rfcid = “RFC-0194” %} {% include “docs/contribute/governance/rfcs/_common/_rfc_header.md” %}
{# Fuchsia RFCs use templates to display various fields from _rfcs.yaml. View the #} {# fully rendered RFCs at https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs #}
NOTE: This RFC is an addendum to RFC-0092 and ratifies decisions that were left open in RFC-0092.
This document:
From the legacy “Session Framework” concept, the following are retained:
session_manager
componentsession_manager
ffx session
developer toolsfuchsia.element.GraphicalPresenter
protocolfuchsia.element.Manager
protocolThe following are discarded or have their ownership transferred to specific product owners:
The following are retained and continue to be owned by the platform but have planned deprecations:
fuchsia.element.Manager
protocolelement_manager
componentThe following open questions from the original RFC-0092 are answered:
When session components were introduced as a concept in RFC-0092, questions about platform-provided capabilities to the session were largely open. Since then, Fuchsia platform designers have learned enough to provide detail about what capabilities are provided to all sessions and, importantly, what types of capabilities will never be provided.
In its role as one of the significant security boundaries between platform software and product software, the choice of which capabilities are provided to the session component is of high importance to the Fuchsia platform designers. Providing an overly broad set of capabilities to all sessions can lock the platform out of providing key consistencies in behavior across all products.
Lastly, the legacy “Session Framework” concept has caused some developer confusion. The concepts, some of which were not explicitly included in RFC-0092 but were in the Session Framework concept docs, originally included:
Due to the open-ended scope of “Session Framework the project”, the term also became open-ended and ambiguous.
Facilitator:
Reviewers:
This section to be updated during the review.
Graphics: emircan@google.com, dworsham@google.com Input: neelsa@google.com Product: yaar@google.com User Data Protection: jsankey@google.com Identity: jsankey@google.com Workstation: sanjayc@google.com
Consulted:
Socialization:
Draft doc was sent to the Scenic, Input, Workstation, Trusted Platform Services teams for discussion.
A “session component” is a component. Each Fuchsia product encapsulates its user experience within a session component (and its descendent components). The term “user experience” is used broadly: it encompasses traditional graphical experiences with touch/mouse/keyboard interaction, as well as simpler experiences with a single RGB LED and several hardware buttons, or those with only network I/O.
Simple products may specify a session component with no children, while complex products have many children of the session component. For example, the workstation session instantiates components to display the system user interface, a command line shell, and a web browser as descendants of its session component.
Today, a single session component is present in the component topology of any Fuchsia product. In the future, multiple sessions running concurrently is expected. The identity (URL) of the session component is chosen by the product owner. The position within the topology is defined by the platform and cannot be changed by product owners. Due to the nature of the component architecture, the session component cannot learn of its position within the topology.
The session component is offered all platform-provided capabilities needed to create the user experience of that product. The session component is one of the most privileged non-platform components in the component topology. For this reason, the definition of the boundary between the platform and the session component serves as an important security and control layer for Fuchsia.
The session component is a child of session_manager.cml
, which is a child of core.cml
. session_manager.cml
is an intermediary platform binary that enables key behaviors:
core.cml
or any other platform .cml
filesession_manager
(by convention, this is used on “paused” variants of eng builds)session_manager.cml
configures the definitive upper bound of capabilities that can pass from the platform to the product.
Like any component, the parent of the session component defines the session component‘s sandbox. Below is an incomplete list of the superset of capabilities that are available to the session component from the platform. Depending on the product’s configuration of the platform, some capabilities will not be available at runtime.
Product configuration, and thus the set of capabilites actually available to a given session component on a given product, is accomplished today through adding or removing build-time package dependencies on a set of product package labels.
The session component can:
For products that have a graphical user interface:
The session component is offered the necessary capabilites to specify a single View to act as the root View of the user experience. The choice of View can change over a session's lifecycle. For example, when interaction with a session is locked due to inactivity, the root view may swap to a lock screen.
Additionally, the session can embed sub-views in its root View for the purposes of delegating to additional software. The ability to embed sub-views is not unique to sessions: it is a property of Fuchsia's system compositor.
Sessions are not required to specify a View. For example: headless sessions running on headless devices would not specify a View.
The following sensitive capabilities are explicitly not provided to sessions:
The session component is offered capabilities that allow it to observe input events. They include routing of key events to focused Views in a View hierarchy, routing of mouse and touch events, and the ability to register for notification of keyboard shortcuts. Additional input capabilities may be required in the future to support interaction with other input devices, both virtual and physical.
The following sensitive capabilities are explicitly not provided to sessions:
The session can access and manage system setting such as the software update channel and active WiFi network, including:
The session is provided with the necessary capabilities to supply encrypted storage to components inside the session. These include encrypted device storage capabilities and the account management service. The account management service may be used to perform authentication and access account encrypted storage.
The session_manager.cml
component contains the definitive list of capabilities offered to sessions. Select capabilities that pose a security or privacy risk will result in a platform build failure if included in session_manager.cml
.
The list of disallowed capabilities will be generated and maintained in collaboration with the Fuchsia Security team. Candidates include:
fuchsia.hardware.display.controller.*
/dev/class/input-report
The capabilities the platform delivers to the session component constrain the session component‘s abilities. This has important implications: a session component that is granted the ability to launch third party software as a child of itself could learn a lot about those instances of the software. For example: it owns persistent storage for its child instances and could be configured to read from and write to that storage. It can also learn the software’s identity (URL), among other information.
The platform session_manager.cml
component configures the upper bound of all capabilities possible to be granted from the platform to the session component. It is the responsibility of the Fuchsia security team to audit this superset and ensure it is suitable for all possible products. Any changes to these capabilities must go through a security review.
Product owners are responsible for the security properties of capability routing once on the product-side of the session component boundary: any routing decisions made within the session component or its children are not visible to the Fuchsia platform security team.
Some auditing and enforcement tools exist today. These include:
fx scrutiny
Improved auditing and enforcement tools are needed to support product-specific security teams. It is the intent of the Component Framework team to improve both scrutiny
and routing allow-list mechanism for better recursion, making it easier to apply the tools to component sub-topologies other than the platform root. However, no specific plans are available at this time.
For now, Security team will be auto-CC'ed on CLs that change either session_manager.cml
or the BUILD.gn
file responsible for compiling the .cml
file.
The privacy implications of having a session component are similar to those for security. While Fuchsia platform can issue guidelines and best practices to session owners, it has no mechanism to enforce policy other than restricting the capabilities (and their respective backing implementations) provided to the session component.
The existing Session Framework documentation will be updated or removed to align with the content in this document.
No alternatives aside from the default of “do nothing”. The risk therein includes the perpetuation of an outdated concept (“Session Framework”) that is causing confusion, and does not currently have a dedicated team to reduce the ambiguity or solve technical issues.