I’m not talking about authentication bypasses. That has (to me at least) nothing to do with this. For me, this is about what a user can and cannot do in the system once they have successfully authenticated.
I find the fact that my 13 year old son has an account on my HA instance that can completely delete all my automations, comprises a security risk. I haven’t read the auditing report but I don’t quite understand why they think this is just fine.
2 Likes
Again,
6 Likes
I don’t know enough about IT security to what is considered a security hole and what isn’t. To me, the fact my 13 year old son has an account on my HA instance that can delete all of my automations is a risk to the security of my home automation system. If there is a more accurate technical term for this risk I am glad to be educated.
BTW, you were the one that brought up security holes in the first place stating more or less that a half-arsed implementation of RBAC would lead to security holes, and when I argued that the current implementation of RBAC already has security holes, you brought up an audit that says there are no authentication bypasses, which in my mind is unrelated. Can you give me an example how an incomplete implementation of RBAC would create a security hole that is worse than what we have now? (No sarcasm intended, I’m not trying to win an argument here, trying to determine whether this is a matter of taste/preference or I am lacking knowledge)
That’s a matter of expectation management, isn’t it? I would prefer that they roll it out like they are doing with the voice. Start with small steps and let people know more is coming. They could have also waited with releasing that until it had everything people expected from voice control if they were switching from Google or Alexa. But by making clear that this was a lengthy process, and features would be implemented one at a time, I think they did pretty well with the expectation management.
My point is that there is RBAC now. There is just only one role and it has access to everything.
Why couldn’t you improve RBAC from what it is now and release it with the explicit message that it isn’t watertight, but it’s better than nothing?
Right now my only mitigation is either to use the setting that hides all the settings from my kids, which is neither secure nor practical, or not giving them an account at all, which is secure but not practical.
Also, in my mind this issue is fully separate from authentication, I think ‘authorization’ is the more correct term?
2 Likes
Sure.
Imagine creating a guest account for your B&B that has Home Assistant, assuming that your guests had no access to your secrets file, yet because of the poor implementation this assumption was unfounded.
Where as at the moment you know they would have access to it thus it is not a ‘hole’ but a missing feature and you should not give untrusted users access.
5 Likes
None taken
Let’s take an example of a fairly well implemented security system. Windows Hello
Windows hello is pretty good. But can be completely bypassed with a bad implementation of say a certain fingerprint scanner. (yes this is a real thing - and is being dealt with in the biz.) so the it admin implements Hello with biometric auth because they think they’re covered but hey hammered by someone who notices the bad fingerprint scanner choice in the laptop fleet of company x.
Whats worse - thinking you’re good and getting hammered or pre Hello implementation when they didn’t trust the fingerprint reader? (and didn’t turn it on)
Right now you know you need to go into the UI for dashboards and panels and throw visibility switches that you don’t want the non admin to access. But what if you thought the system had it handled for you?
I guess it is a matter of taste, then. I think there are already people who give out guest accounts without fully realizing the risk that implies, and I also think that a system that makes it harder for some users - even if not completely impossible - to access certain features, with the proper communication about the limitations, would be better than the current system.
Anyone who’s seen a James Bond movie knows it’s possible to fake a fingerprint (though I’ve been told it’s not as easy as it is in the movies).
Of course the more secure option would be not to use any authentication method for regular users, but to only have computers operated by specially selected employees, who have root access to everything. Anyone else that needs to send an email stands in line at their desk and dictates the content to the computer operators 
I feel this is where we are with HA now. And it may look secure from a certain standpoint but I don’t think it is. Because if you make it extremely impractical for people to do things in a secure way, they will just go around it and do it in a very insecure way.
I think good communication about the limitations is key here.
(BTW, is there a way to throw visibility switches for individual users on anything else than complete dashboards? I didn’t even know)
1 Like
(No it’s not that easy to fool a fingerprint reader. That said go passkeys. Waaaaay better)
I any dashboard hit edit
Now you see the icons for the views across the top… Hit the edit pencil next to the one you want to work with. Here I picked my ‘rooms’ dashboard and I’m going to edit the it closet view. (there’s no reason for a guest to see that in my panel)
Once you’re Iin there look at the tab on the top right. - visibility.
Kill the toggle for anyone you don’t need in the view.
That said do NOT mistake this for security. It’s not. You still need to be careful not to expose stuff you should not
But it keeps the riff raff out of my stuff in public panels. Notice I take a default off mentally…
But that’s for the views, no? I knew that one. For a moment I thought you meant this could be done on individual cards.
1 Like
No view level.
For specific cards I create two separate views for different user types of its that complicated s Or use custom cards that have the ability to show/hide cards based on user context.
Edit: in fact ‘conditional card’ just got an update to support user as a condition…
Very much a pain and I would rather not. But it’s what I have to do to trust leaving an open panel in my hall with friends who like to test my stuff.
Aha! Thanks for this information. I haven’t used conditional cards before, but it seems quite useful
2 Likes
My kids can effortlessly locate smart plugs controlling the boiler through the logbook. This poses a risk of inadvertently disrupting our home’s systems, including disrupting our internet connection. I’d prefer selectively exposing Home Assistant devices through Apple HomeKit to a shared iOS device.
I’ve thought about this problem a bit. I’ve considered creating another instance of Home Assistant that can interact with the primary instance in a limited fashion. It’s pretty much the only option I see right now. Worst case they tank the secondary instance which would be backed up and not have access to anything important in the primary instance.
2 Likes
For that purpose it’s possible to build custom dashboard app which will only expose what the user need and use any security measures to protect the hardware from tempering.
Home Automation is always at risk of tempering by your guests but you trust them to not unmount your lighting so you can trust them to not temper your racks and your wallscreen.
Home Assistant wasn’t made for guests but you can easily use HA as a backend and only give your guests access to a remote or a wallscreen.
After all in many public places they are protecting the hardware, not the software.
On a kiosk without keyboard and no USB port you don’t have to disable ctrl+shit+del interacions.
Coffee machines are controlled by a touchscreen on a Windows software, the same is done for ATM and photo booth (and yes it does run Doom)
It feels odd to me that we have the ability to control which entities are exposed to voice assistants, but not which entities are exposed to users. It’s largely irrelevant whether this is technically RBAC. The spirit of what most people in this thread want for users is what was implemented for voice assistants. So it doesn’t have be called RBAC, but implementing “exposing entities to users” would satiate most people in this thread.
On the security front, this is the first paragraph of exposing devices:
To be able to control your devices over a voice command, you must expose your entities to Assist. This is to avoid that sensitive devices, such as locks and garage doors, can inadvertently be controlled by voice commands.
Sounds like that’s what most people in this thread are concerned about regarding security.
In any case, it seems like the solution to this thread already exists in HA. It just needs to be implemented for users.
3 Likes
There are so many use cases for that.
Also for the gardinier or home assistant, to unlock doors, or warter valve,…
So these users get rerstricted to special devices.
In my opinion the easiest way would be to have user groups and add users to these groups.
RBAC would be the right word, because this is how it is named in the industry.
The second option would be to lock a user to a dashboard, so he cant get to another dashboard.
However, this is needed really.
Thank you all for your support.
Kind regards
Antonio
User groups already exist in HA. The issue is that the default groups are basically Admin and User and the only way to add other groups is by YAML editing. The rest of the security subsystem for HA has never really been built out even though it’s been there for a few years now!
@joneshf does make a valid point that they put in the effort to doe entity exposure for voice assistants and the system would in theory be something that could also be leveraged for user exposure I would think. Getting that would be a big win for folks that want to provide access to untrusted people.
Mostly agree. One key difference, however… RBAC isn’t super hard to do right if it’s part of the original design. If it’s not, then yes, it’s hard, but the more other things that get developed before it gets designed in, the harder it gets. As such, I would argue that at least having an architectural plan for how RBAC will work and how it gets integrated into the code is the urgent ask so that we can get to a point where all future development is done with RBAC in mind and ideally baked in.
Fully agree. It’s strange that such an important set of features haven’t been implemented yet.