Hi all,
Quick note before diving in: I’m posting this before writing any code , specifically to check whether this direction is something the community and maintainers would actually want, rather than showing up later with a PR built on assumptions nobody agreed with. If the consensus is “this doesn’t fit” or “this was already tried,” I’d rather find that out now. Its also my first post here!
I’m a DevSecOps engineer (blue team, not an offensive security person), and I recently put together a security workshop for university students using Home Assistant as the target platform. The goal was to demonstrate the security implications of running a malicious or “sideloaded” third-party app with broad privileges.
While building the workshop, I came across something that I think is worth discussing at the platform level: the trust model around app permissions is largely based on what an app declares it needs, rather than on giving the user a clear understanding of the resulting privileges or providing strong visibility into how those privileges are subsequently used.
I’m deliberately keeping the discussion at the architectural level here rather than proposing a specific implementation.
The current problem
Addons can request different levels of access through mechanisms such as hassio_role , hassio_api , homeassistant_api , docker_api , full_access , etc.
The important question for me isn’t whether these mechanisms are technically correct — they clearly serve a purpose — but rather:
How does a Home Assistant user understand and monitor the security implications of granting those permissions to an app?
Today, much of that trust decision happens at installation/configuration time. Once an app has been granted a privilege, there is comparatively little user-facing visibility into:
- What that privilege actually allows the app to do.
- Why the app needs it.
- Which privileged operations the app subsequently performs.
- Whether its behaviour changes over time.
- What evidence would be available if the app were compromised.
This creates an interesting asymmetry: an honest app author has to request the privileges they need, but the platform doesn’t necessarily make the principle of least privilege particularly visible to the user — and a malicious app can potentially benefit from the same trust model.
Permission badges and signalling
There is also a smaller but related UX issue that caught my attention.
The permission/access badges displayed for app can be difficult to interpret from a security perspective. In particular, a blue badge associated with Supervisor API access can, at least to me, visually suggest something closer to an “official”/trusted status rather than “this app has access to a highly privileged API.”
I’m not suggesting that this is the intended meaning of the badge, but I think the distinction matters.
A security-sensitive permission should ideally communicate risk/capability , not accidentally look like a trust or endorsement signal.
Perhaps permissions should be visually and semantically separated from things that indicate app origin, repository status, or official Home Assistant support.
What I observed while building the workshop
While experimenting with intentionally malicious apps, I was able to demonstrate some scenarios where an app with broad privileges could have consequences far beyond the app itself.
One particularly interesting example involved granting an app Supervisor-level privileges.
In the workshop scenario, those privileges allowed the app to perform a sensitive authentication operation such as resetting a user’s password. Once the password had been changed, the addon could establish an outbound reverse tunnel, allowing the attacker to reach the Home Assistant instance remotely and authenticate using the newly controlled credentials. That with good looking badges!
The important point here isn’t the specific attack chain — it was intentionally constructed for a controlled workshop environment.
The interesting part from a platform-security perspective was the blast radius of the initial permission grant .
A user installing an app may think:
“I’m installing an app that does X.”
But the actual security decision may be closer to:
“I’m allowing this software to perform privileged operations against my Home Assistant instance.”
I think that distinction deserves much more visibility.
I also found that some of the existing isolation mechanisms are difficult for users to reason about. For example, an AppArmor profile being present does not necessarily tell a user how restrictive that profile actually is. There is potentially a useful distinction between having a security control configured and having a security control that provides meaningful containment .
I’m not suggesting that these mechanisms are ineffective or that Home Assistant’s current security model is fundamentally broken. Rather, I think there may be an opportunity to make the trust boundaries more explicit and observable.
What I’m proposing
I’d like to explore three related changes at the Supervisor level.
1. Explicit, human-readable app permissions
At installation time, instead of presenting permissions primarily as technical capabilities, expose a human-readable summary of what the app would be allowed to do.
For example:
This app requests elevated Home Assistant access
- Can restart Home Assistant
- Can modify Home Assistant configuration
- Can perform privileged Supervisor operations
- Can access X
The exact permission categories would obviously need discussion.
The important idea is that users should be able to make an informed security decision without having to understand Supervisor APIs, Docker capabilities, AppArmor or the app configuration format .
This could potentially be combined with risk tiers, so that low-risk permissions don’t create unnecessary friction while particularly sensitive permissions receive more explicit confirmation.
2. Supervisor-level security auditing for apps
The second idea is to make privileged app activity auditable.
Rather than only having technical logs, I’d like to explore the possibility of Supervisor maintaining a security-oriented audit trail such as:
addon X → privileged Supervisor operation Y → timestamp
The goal wouldn’t necessarily be to log every internal operation forever. Even a relatively small audit trail for security-sensitive actions could be valuable.
This would make it possible to answer questions such as:
- Which app performed this privileged operation?
- When did it happen?
- Has this app used this capability before?
- Did its behaviour change after an update?
The key distinction I’m interested in is between ordinary application logging and security auditing : the latter should make it straightforward to attribute sensitive actions to the app that performed them.
3. Security notifications for high-impact operations
Building on the audit trail, I think there is an opportunity for Supervisor to actively notify the Home Assistant administrator when an app performs particularly sensitive security operations.
For example:
Security alert: App X changed a Home Assistant user’s password.
Or potentially:
Security alert: App X performed a high-risk authentication operation.
I don’t think every Supervisor API call should necessarily generate a notification. That would quickly become unusable.
Instead, there could be a small set of high-impact security events where notifying the administrator makes sense — authentication changes, credential/token operations, or other actions capable of materially changing the security posture of the instance.
This would address an important gap between auditability after the fact and detection while an attack is happening .
A compromised app shouldn’t necessarily be able to silently perform a major security-sensitive operation and leave the administrator unaware until they investigate logs.
Secondary question: validating isolation
A related, but probably separate, discussion is whether Home Assistant could provide better feedback about the quality of app isolation.
For example, an AppArmor profile that is technically present but extremely broad may deserve a different security assessment from one that is carefully scoped.
This could potentially involve better validation of app security policies, stricter defaults, or eventually other sandboxing mechanisms.
I’m mentioning this as a related direction rather than proposing that AppArmor itself should be replaced or redesigned as part of this proposal.
Why I think this could help
The underlying idea is to move more of the trust decision towards the layer that can actually understand and mediate app privileges: the Supervisor.
Today, addon security is partly expressed through technical configuration and isolation mechanisms that are primarily meaningful to developers and administrators with a fairly deep understanding of the platform.
I think there is an opportunity to make that model more explicit:
Before installation:
“What exactly am I allowing this app to do?”
During operation:
“What privileged actions is this app performing?”
When something unusual happens:
“Why am I being warned that this app just changed a user’s password?”
After an incident:
“What did this app actually do?”
None of these mechanisms would prevent a compromised app on their own. The goal is instead to improve least privilege, transparency, accountability and detection .
Where I’m not sure
There are several design questions where I’d specifically like community input:
How much of this belongs in Supervisor itself versus an optional security/auditing component?I first started by developing a demo app that handles this kind of things, but it was as dangerous as a malicious app
- Would a permission confirmation UI actually improve security, or would users simply develop permission fatigue? Not directly but at least raises users knowledge of what they are installing.
- Would risk tiers or confirmation only for high-impact permissions be more appropriate?
- What subset of Supervisor/addon activity would actually be useful to audit?
- Which operations are sufficiently security-sensitive to justify an immediate notification?
- Should notifications be configurable, or should certain high-impact events always generate one? I would say a subset of events, but configurations are always nice.
- What are the storage and performance implications on constrained hardware?
- How much security information should be exposed to normal users versus advanced users?
- Is improving addon permission visibility the right direction, or should the focus instead be on fundamentally stronger app isolation?
- Should permission badges be redesigned so that they communicate capability/risk rather than potentially being interpreted as a trust or endorsement signal? This is kind of alarming in my opinion, I´ll update the post with examples
Questions for the community
- Has an app permission/consent model like this been discussed before?
- Has Supervisor-level auditing of app activity been considered?
- Has there been previous discussion around security notifications for sensitive app actions?
- If any of these ideas have previously been rejected, what were the main reasons?
- Do you think this addresses a real security/usability problem, or is the current model sufficient?
- Do you think the current permission badges communicate app privileges clearly enough?
- For maintainers and app developers: does this seem like a useful direction for a design discussion, or would you prefer this to be explored differently?
I’m intentionally not proposing a concrete implementation yet . I’d first like to establish whether the underlying problem is real and whether there is a direction that makes sense for Home Assistant.
I´m also aware that this is dangerous more or mostly only towards third-party apps, but I still think we should aim to improve the security posture for those, rather than saying ´hey this is not official, you are on your own with what ever you are installing´
If there is interest, I can share more detail about the workshop and the threat model I used.
Thanks!