Clickbait? Yes. Now that I have you here, a proposal:
I theorize that by examining the App Armor profile, we can enumerate potentially harmful activities which may be useful for determining actions taken by add-ons. I submit to you a potential solution to make headway on the eternal question which everyone without time to audit add-on source code has…
is this add-on legit?
Android’s permission system is easy to use and audit. The apps declare their permissions within the manifest and request them from the user at runtime. Similarly, add-ons are granted a set of default permissions by Docker, or their apparmor.txt. While we cannot request permissions in real-time, we can allow the user to review and authorize at the time of installation or upgrade.
The names and descriptions of the actions could be displayed to the user for approval, and stored in a database for future reference. In the event an automatic update is pushed out, or permissions have changed, the user would be given the opportunity to approve the update before the new add-on software is installed. Optionally, the permissions system could be disabled similar to the methods used to Disable Protection Mode or Automatic Update occurs
This proposed permission system would utilize an Enum of previously identified permissions and scan the add-on for potentially harmful actions at the time of installation. The enum would consist of an Entry. Within the entry is contained a friendly name, a description, and a regex.
"""Definition of Permissions Enum for enumeration, regex identification, and description of AppArmor directives"""
from collections import namedtuple
from enum import Enum
class Permission(namedtuple("Permission", "name description regex"), Enum):
"""Enumeration of potentially harmful permissions"""
MOUNTRW = "Mount RW", "Mount partitions as writable", r"mount.*options=[^\s-]*rw"
DEV = "Devices", "Work with hardware devices", r""
CHANGEPROFILE = "Change Profile", "Modify permissions during operations", r""
BLUETOOTH = "Bluetooth Access", "Bluetooth connection access", r""
PIVOT_ROOT = "Pivot Root", "Change root directory", r""
DBUSEAVESDROP = "DBus Eavesdropping", "Eavesdropping on DBus access", r""
DBUSAUDIT = "DBus Auditing", "Auditing D Bus", r""
AUDIO = "Audio", "Access to audio devices", r""
ACCESSADDONS = "Addons", " Access to locally installed addons ", r""
ACCESSBACKUP = "Backups", "Access to Home Assistant Backups", r""
ACCESSCONFIG = "Config", "Access to files within Home Assistant Config", r""
ACCESSMEDIA = "Media", "Access to files within Home Assistant Media", r""
ACCESSSHARE = "Share", "Access to files within Home Assistant Shared files", r""
ACCESSSSL = "SSL", "Access to files within Home Assistant SSL", r""
def __str__(self) -> str:
return self.name
Which would be accessed as follows:
print(Permission.MOUNTRW.name)
print(Permission.MOUNTRW.description)
print(Permission.MOUNTRW.regex)
| Mount RW
| Mount partitions as writable
| mount.*options=[^\s-]*rw
The Enum Name would be recorded in the database. The name and description would be used for display purposes in requesting user permission. The regex (mostly unpopulated in the above example) would be used to scan the apparmor.txt for patterns which match predetermined patterns.
In the event the add-on author claims apparmor: false, all Permission items would be assumed as declare, since apparmor: false will provide the same protection as such. In the event
I’m interested to hear feedback on this before I go too deep into creating a system which I alone find intriguing but has a low UAF(and WAF) factor. Some of my primary concerns are:
- Does this reduce user experience to go into the gory details that nobody thinks about, or does it enhance the user experience by keeping them informed?
- Does the proposition go too far? Not far enough?
- Should severity factor be implemented or is verbiage in the description enough?
- What would a User Interface look like for the feature after the add-on is given a rating by the back-end?
- Does this proposal address most existing concerns and put your mind at ease when installing random add-ons?
- Is there a better approach?
- Am I completely missing some avenue of approach which could bypass this feature?