Commit 8caee9f8 authored by Simon McVittie's avatar Simon McVittie

Permissions: Add non-use-cases for cameras

This is related to the `<abstractions/cameras>` AppArmor abstraction
mentioned in <https://phabricator.apertis.org/T3586>.

Apertis: https://phabricator.apertis.org/T3515Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
Reviewed-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.co.uk>
Differential Revision: https://phabricator.apertis.org/D6386
parent b0357cc7
......@@ -851,6 +851,28 @@ built-in application that communicates directly with specialized hardware.
These built-in application bundles should have their own AppArmor profiles,
polkit rules and other security metadata.
### Driving cameras
Some vehicles have external cameras for purposes such as facilitating
reversing, watching for hazards in the vehicle's blind spots, or improving
night vision by using thermal imaging.
Our understanding is that images from these cameras should only be made
available to platform components or to specialized built-in app-bundles,
so they are outside the scope of this document.
### Infotainment cameras
[Android] and [iOS] mobile phones and tablets typically have one or more
cameras directed at the user or their surroundings, intended for photography,
videoconferencing, augmented reality and entertainment. Our understanding is
that this is not a normal use-case for an automotive operating system that
should minimize driver distraction.
If a vehicle does have such cameras, their use cases and security
implications are very similar to audio recording, so we believe there
is no need to describe them in detail in this document.
### App-specific permissions
In [Android], any app-bundle can declare its own unique permissions namespaced
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment