Rethinking app permissions at the Supervisor level

[Thurmiel]

Hi all,

I recently put together a security workshop around attacking and compromising Home Assistant instances. As part of it, I created intentionally malicious or "sideloaded" apps to explore what an attacker could do after obtaining control of an app.

The goal wasn't to demonstrate a particular vulnerability, but to explore the blast radius of the privileges available to an app.

The current problem

Apps 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.

What I observed while building the workshop

While experimenting with intentionally malicious apps, I was able to demonstrate several scenarios where an app with broad privileges could have consequences far beyond the app itself.

One example involved an app with Supervisor-level privileges performing a sensitive authentication operation such as resetting a user's password. Combined with an outbound reverse tunnel, this could provide a path for an attacker to remotely reach the Home Assistant instance and authenticate using the newly controlled credentials.

The individual attack chain isn't really the point — it was a controlled workshop environment.

What caught my attention was the blast radius of the initial permission grant.

A user may think:

"I'm installing an app that does X."

But technically they may be granting it the ability to perform highly privileged administrative operations against their Home Assistant instance.

I think that distinction deserves 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

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:

app 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.

A related UX/security-signalling issue

There's also something about the current permission badges that I find potentially confusing.

Some app permissions, such as the blue Supervisor API badge, can arguably be interpreted more like a trust/official-status indicator than a warning that the app has elevated access.

I don't think that's necessarily the intended meaning, but from a user's perspective there is an important distinction between:

"This app is trusted/official"

and

"This app has access to a highly privileged API."

I'd be interested in whether permissions should be visually separated from signals about app origin, trust, or official status — and whether the current badges communicate the security implications clearly enough.

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, app 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.

Questions for the community

• Has an app permission/consent model like this been discussed before?
• 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?

I'm intentionally not proposing a concrete implementation yet. I'd first like to establish whether the underlying problem make sense for mo more people (altough i already got a feeling in the workshop) and whether there is a direction that makes sense for Home Assistant

Thanks!

[Thurmiel]

Pasting here a response to this topic in Discord from user xxx3780#:

Some of my questions for ur post I guess would be:
What is your basis to come up such permission issue? It looks like you did some pen testing
or sec. testing yourself on HA, but what are those?
Does what you found was based or align with OWASP? Because I cannot see it from what u wrote.
If it is align with OWASP, maybe i would suggest to present each of those issues categorically and maybe create a sub goup
3.1. UI issue:
3.2. Backend issue:
3.3. Core issue, OS issue, Integration issue, etc...
Maybe if you find some issues/vulnerability, list them here as well.

For me, I would probably wanna know if there are vulnerabilities that exists within what you discuss here(as it may seems so).
That way we can patch it up asap, no bs and all that stuff. I also wanna know what replaces AppArmor that you seems to have discussed just so everyone would know. I know we all want a secured HA since we all use it and the community would benefit from it. Not just the community but the integrators as well.. But.., feelings are not logical in dealing with logical systems and should never become a basis, dont u think. 😅 This is good stuff btw..

p.s. Just to set things straight, im just a volunteer, not in anyway tied with any comp. here or paid by them. Just trying to help out based on my experience in the IT field

[Thurmiel]

How this started

First things first, I'm a cybersec guy and a cybersec association proposed me to bring up a cybersec-related workshop about whatever I liked.

Lately I've been learning/reading about supply chain attacks, and from my experience with HA I suspected I could find interesting things in the apps/addons.

The main idea was: given a useful, legitimate app, could I just push an update for it and turn it malicious without the user being aware? I know that's not a supply chain attack "by the book" which would usually involve compromising the vendor's build/release pipeline itself, not just pushing a new version of an app you already control. What I built is closer to simulating the end state of a supply chain attack (a trusted, already-installed app going bad on update) without actually compromising a pipeline to get there.

Then I copied the demo app on GitHub but added a very basic and noticeable reverse shell, then installed it on a HAOS instance, and from that shell started playing around.

Can you call that pen testing? I guess. I wasn't following a scoped methodology, so I'd rather call it hands-on security testing / threat modeling than claim "pentest" outright.

---

I was not looking for anything specific, nor for vulnerabilities in the sense of exploiting a bug, just exploring what an app, with the permissions it can legitimately request, can potentially do.

Without exploring much, I realized that with Supervisor API privilege, an app can legitimately change a user's password. Then, with no malicious packages installed in the app itself, you can open a reverse tunnel and log in as any user whose password you just changed. (I was trying to showcase the thing pretty visually)

Can we categorize this into an OWASP vulnerability? Not directly, there's no CVE-style bug here, and it's not a single named OWASP entry. It doesn't map cleanly to a single OWASP category. Some aspects are related to Broken Access Control, excessive privileges/least privilege, and Security Misconfiguration, but I wouldn't force a stricter mapping.

I'd now call these findings, not vulnerabilities. From a threat modeling perspective, nothing here is a bug in the traditional sense, the software is doing exactly what it was told to do. What's missing is a control: visibility and friction around a legitimate permission being used and what the user perceives.

Now the findings, per ¨category¨:

UI findings

The badges shown on addon pages aren't meaningful enough from a security perspective. E.g. for the Supervisor scenario described above, it shows a blue badge with the HA logo saying "Home Assistant API" and "Admin", ans app armor shows green even when the profiles does nothing.

Which does communicate that the addon wants it, but for a non-technical user that doesn't ring any alarms. If anything, from that user's perspective it reads as "oh, this is supported/official," which is the opposite of the intended signal.

AppArmor (UI-related)

The app developer can enable it and set a very permissive profile, and it'll still show a green badge with a good score.

AppArmor (as a tool)

It's probably the right tool, but the fact that a developer can disable it, or set a permissive profile, with no control on that, makes it inert in practice, IMO. I'm not an expert in this tooling and I'm not even proposing a replacement, just making sure that using it correctly is actually enforced, not optional.

Logging and alerting

Not a finding on its own, but I'd want certain actions to trigger a notification for the admin — e.g. "App X changed user Y's password." Is that useful for a non-technical user? Probably not in full detail, but enough for them to worry and reach out for help.

---

That said, I'm not sure I understood your message properly.
I didn't come up with this based on feelings. I did a threat modeling exercise here, plus pentesting (I feel a bit odd calling it that, since I know very little about offensive security).

I intentionally didn't write about where in the architecture (core, OS, Supervisor, etc.) each thing should be fixed, so as not to lose focus. But from what I understand of the docs and HA's architecture, all the findings/proposals here would land at the Supervisor level, since that's the component installing, scoring, and running the apps.

Btw, I didn't explore integrations, gut instinct (now its feelings writting, haha) is that similar findings could show up there too. I didn't go that route for the workshop because, for a regular user, installing a risky integration requires a lot more steps (HACS) and knowledge than installing an addon, IMO.

I'm just an HA user who happens to work in cybersec and got the chance to play around with HA.