Security considerations

Static files

Static files used by the system must be read-only files that are protected from being modified. We recommend the files are stored on a read-only, integrity-checked filesystem, such as the Merkle filesystem, or within the IFS, if it's protected by a trusted boot process.

The Sensor services uses the following static files in the form of configuration files when it starts:

Sensor configuration file, which is used to identify and configure the cameras and sensors used by the system. For more information, see “Sensor configuration file.”
Interim Data configuration file, which is used to identify the interim data units that correspond to interim data. For more information, see “Interim data configuration file.”

The reference images that we provide have examples that are stored in the /etc/system/config directory. These examples are specific to each hardware platform. For more information, see the “Configure sensors and cameras on the reference image” section in the Getting Started Guide for a particular platform.

In addition to the configuration files used by the Sensor service, System Launch and Monitor (SLM) files are used. These files allow you to modify the startup sequence of applications and services without rebuilding the target image. The same guidelines apply to these files. For more information about SLM files, see “System Launch and Monitor (slm).”

Dynamic files

Dynamic files used by the system must be given appropriate permissions that match those with which the process executes. Consideration should be given as to whether any personally identifiable information is recorded and whether the files should be stored on an encrypted filesystem.

The Sensor service interacts with these libraries. Summarized are the calls that create dynamic files:

ADAS library:

adas_record_start()
adas_record_stop()

Camera library:

camera_roll_get_path()
camera_roll_set_path
camera_roll_open_video()
camera_roll_close_video()
camera_set_filename()
camera_start_encode()
camera_stop_encode()
camera_start_video()
camera_stop_video()
camera_roll_set_filename_suffix()

Sensor library:

sensor_roll_open_file()
sensor_roll_close_file()
sensor_roll_set_filename_suffix()
sensor_roll_set_path()
sensor_roll_set_path()
sensor_start_recording()
sensor_stop_recording()

For more information about the functions, see the descriptions in these guides:

Rootless Operations

A system should minimize the need to use and retain root privileges for processes and services. The Sensor service must be started as root, but it drops privilege to a non-root user after initialization completes. Client processes must be a member of the same group as the Sensor service to successfully connect. The -U 521:521 option should be given on the command line to specify the runtime user:group. The Sensor service requires the following procmgr abilities for proper operation (and automatically ensures the necessary abilities are retained when its privileges are dropped):

PROCMGR_AID_PATHSPACE
PROCMGR_AID_MEM_PEER
PROCMGR_AID_MEM_SPECIAL
PROCMGR_AID_MEM_PHYS
PROCMGR_AID_MEM_LOCK
PROCMGR_AID_SETUID
PROCMGR_AID_SPAWN
PROCMGR_AID_FORK
PROCMGR_AID_PROT_EXEC
PROCMGR_AID_KEYDATA
PROCMGR_AID_PRIORITY
PROCMGR_AID_INTERRUPT

Mandatory Access Control (MAC)

A security policy for a system controls where a process can attach channels in the path space, defines which abilities to assign to its processes, and controls which processes can connect to which others. Access control is a mechanism used to secure a system by limiting the actions available to a process. Mandatory access control (MAC) is policy-driven, with rules to enforce relationships between processes, channels, and paths. For example, rules control which processes can connect to a channel, as well as which specific paths a process may attach to in the path space. This restricts the ability of a process to connect to a channel.

The Sensor service registers names within the path space, and allows connections from clients and connections to other servers. If a system security policy is used, it must contain rules to allow these behaviors and the Sensor service should be started with the appropriate type. For example:

type ss_t;
type ss_client_t;
allow_attach ss_t /dev/sensor;
allow ss_client_t ss_t : channel connect;

For more information, see the “Security Policies” chapter in the System Security Guide.

Startup

The Sensor service and its clients should be started with the appropriate permissions and use the appropriate types if a MAC policy is used. For example, here's how to start the Sensor and the ADAS example applications:

on -t ss_t sensor -U521:521 -r /accounts/1000/shared/sensor -c etc/system/config/adas_example_capture.conf
on -t ss_client_t adas_example -c base/etc/system/config/adas_camera_sensors.conf -m script

If you are using a SLM file, you can run the same commands. For example, you can modify an existing SLM file provided to you in the reference images:

<SLM:component name="sensor">
    <SLM:command>/base/bin/on</SLM:command>
    <SLM:args>-t ss_t /base/bin/sensor -U 521:521,1001 -r /accounts/1000/shared/camera -c
                  /base/etc/system/config/adas_example_capture.conf</SLM:args>
    <SLM:depend>resarb</SLM:depend>
    <SLM:depend>screen-ready</SLM:depend>
    <SLM:waitfor wait="pathname">/dev/sensor/sensor5</SLM:waitfor>
</SLM:component>
<SLM:component name="adas_example">
    <SLM:command>/base/bin/on</SLM:command>
    <SLM:args>-t ss_t /base/usr/bin/adas_example 
              -c /base/etc/system/config/adas_camera_sensors.conf -m script</SLM:args>
    <SLM:depend>sensor</SLM:depend>
    <SLM:stop stop="signal">SIGTERM</SLM:stop>
</SLM:component>