I see this is super high in Feature requests. Personaly as HAAS is getting significantly better every day, I miss this more and more every day.
Is this being developed? I assumed there will be updated roadmap due to state of the open home, but while I watched it, I dont see there was any roadmap update at all.
It’s likely part of the topic of security, and because of how deep into the system they would have to go to properly implement it, they can’t give us an exact timeframe for it being added. One thing that they have to do is make it work as it does currently because a lot of long term users won’t want to reconfigure their systems to be able to have it work as it currently does.
I’m surprised this hasn’t been implimented. Everyone has multiple applications for this especially in a family enviroment.
I’m not; most smart people would rather the developers took their time and did it right than just throw something together to satisfy a very vocal group of users on the forums and github. And personally, even with family in the house, I wouldn’t have a need for this, because I wouldn’t be giving anyone else access directly to the web interface.
I think this idea that the developers are just “taking their time to get it right” is a red herring. That isn’t really a realistic mindset with something like RBAC because the more stuff you keep adding, the more stuff you need to change later if you do implement RBAC.
Hate it break it to everyone, but RBAC isn’t coming. At least nothing that will withstand more than casual atttempts to circumvent it. Security needs to be designed in from the beginning or it’s a massive massive undertaking that will stop all other feature work AND break existing stuff. It’s painful, and even then, it’s going to take iteration and time. I just don’t see this happening for HA which favors “add a bunch of crap really quickly and move on to the next thing” style development (which is great for a FOSS project! HA is awesome). There wouldn’t be nearly as many contributions if every change needed a security evaluation. Software engineering is frankly pretty easy if you don’t need to deal with securtity. Security multiplies the cost of a feature by 5-10x, easily. At least if you do it right, which again, needs to happen from the beginning.
Hate to be the bearer of bad news but HA is far more insecure than you could have imagined. All of the credentials you’ve ever typed in to log into an integration are stored on disk unencrypted. There is also no sandboxing between integrations or addons or anything, so any integration can straight up read credentials from any other integration. There is obviously no restriction on sending web requests (you’ve never had to approve an integration talking to server XYZ) so someone could pretty trivially write an integration that is useful, build it up to gain popularity, add some innocuous looking code that extracts session tokens, api tokens, usernames / passwords, etc + sends it off to a cloud host (but keep it deactivated), then finally turn it on and watch the passwords stream in.
Yes, it will probably be noticed relatively quickly because some people do monitor this stuff. But if they purposefully weeded out intelligent people in a way that kept the popularity limited (eg., a combination daily bible verse and inspirational Trump quote lovelace card), it could theoretically take quite a while. Fewer people using it means less likelihood any of them will be monitoring outgoing traffic. And limiting the audience to a group of people who are less likely to think critically about things is a classic strategy to scam people (this is why spam and scams will have obvious typos, they help filter out people who won’t fall for the scam anyway).
Does this mean those AirBnB guests can access all of this info? Darn tootin’! Could some integration/add-on/HACS component already be doing this today. Obviously. I haven’t mentioned it because I don’t want my own stuff to get hacked, but that’s not really a good security strategy. Someone is going to figure this out.
Obviously the devs are well aware of this. I can’t imagine any scenario in which you could meaningfully contribute code to HA and not be aware of this. It’s pretty obvious, go look for yourself. There is a folder called /config. In this folder is a hidden folder. Within that folder is all of your internal HA data.
If you can install add-ons, just install the VS Code add-on, enable ‘show hidden files’ in the settings and you can browse right to it and view everything.
I know the topic is RBAC, but this is clearly related. For one thing, it doesn’t really make much sense to implement RBAC on top of a system like this. The security issues here are far more fundamental because they don’t require any local access and the stakes are a bit higher than deleting automations or whatever. 2nd, because RBAC also doesn’t exist, any LOCAL user can ALSO extract your credentials, trivially. I have no doubt they could even extract a session token they could put on their own computer that would allow them to auth with your HA instance and fully extract whatever data they want, or install a backdoor.
The limit here is the capability of the attacker, the relative unpopularity of HA (techie people know what it is, but few outside of that) and the fact that no one really cares about your data. Home Assistant itself is built on the premise of “always trust everything automatically all the time” with a few random efforts at reining that in. Any meaningful change seems pretty unlikely (basically 0% chance) because it would require rewriting ANYTHING that depends on those assumptions. And that type of work just isn’t fun. Ain’t gonna happen.
EDIT: I will say, it’s a bit of hyperbole to say ALL of your credentials for EVERYTHING are stored there. They obviously should never need to store your username/password, that’s what session tokens are for. But I do know my iCloud creds were right there, plain as day. And they will need to store a token of some sort or the integration would not integrate very well, so this is somewhat unavoidable. I mean, this is pretty much the worst possible way to do it, but the tokens do need to live somewhere.
Make sure you’re using MFA and unique passwords on every single site, buckos.
Regarding the plain text credentials:
This is something that every application has to do if it has to authenticate against a third party server using basic, digest or another similar authentication.
As much as I know Wifi passwords in android are also easily readable, how else should it be possible to share it with a QR code?
Thats one reason why OAuth is becoming more and more popular and some integrations in HA are already using it meaning there are no plain text passwords stored.
Also secrets for the yaml files are simply stored in a “secrets” file, which is only there to not store it in version control.
Regarding RBAC, I wouldn’t say that it gets more and more difficult if more features are added. With RBAC you probably define which devices, entities etc. are accessible for which roles. As integrations usually only provide entities and devices, they shouldn’t care much about RBAC at all.
Obviously there are exceptions like integrations that add their own menu entries which might have to add the ability to display / hide that entry for specific roles.
For dashboard layouts and cards it is a more work as they have to decide how to handle inaccessible entities.
So I don’t want to say that it is easy, for sure it’s not, but I think that most new features won’t affect how hard it is to implement.
security is something that needs to improve as the HAAS grows. I think RBAC is not needed now, but to have another user role (currently user and admin) I think there should be
I was already trying to observe how the HAAS handles trafic of the user.
there is some form of anti-automation against attacker - simple one thats possibly part of websockets. there is JWT as a sort of authentication that was quite strange - I will need to study more.
I have not noticed any problem yet, but I spent just 20
minutes and was trying to understand basic functioning.
What it looks like from my point of view is that there is no security handling on the browser but things are handled by the server. I might be wrong. I will look into it more.
Hello everyone,
I’d really love to see the Logbook/History views get a simple role-based filter so that:
Right now non-admins can effectively gain admin rights by launching service calls from Logbook/History – a serious security gap.
I posted a more detailed feature request (including a demo video) here — the thread is now closed:
It would be fantastic if someone from the core team (or the community) could take a look and implement this straightforward filtering mechanism.
Thanks!
It’s simply ludicrous to say every application stores plaintext credentials unencrypted on disk where anyone with access to the application can copy them, and where any install ‘app’ can read credentials from every other app.
I won’t use Apple as an example because that’s almost cheating (the security is very good).
Let’s use Google Chrome. If I have access to someone’s web browser, can I simply open the password section and copy all of the passwords? No. If I have admin access to the Windows box I can, but I need admin access to the OS. Every typical application that stores credentials a) stores them encrypted on disk, not in plaintext, and b) you need some sort of elevated privilege to access them. Every OS has a granular permissions system that makes this possible.
And the idea that any ‘app’ can read the data from any other app, and there is simply no way to prevent that? Insanity.
Now, I’m not hating on Home Assistant. I think it’s overall great and they have made tradeoffs to build a robust community. But to be frank - it’s actually impossible for anyone to make it secure in any way whatsoever due to the design decisions. It’s one thing to have security and make it opt-in. But there is no opt-in, there is no way to choose anything but full trust for every user and integration and HACS file and any piece of code you ever run.
The idea that we don’t need RBAC “yet”. Lmao. That’s absolutely true, since it’s never going to happen. Security is not something you can just add on later, as should be obvious by how trivial it is to bypass the single limited role they’ve created so far. You need to rewrite so much of the core code it’s going to break every integration. Every integration would need to be updated. I personally do not see that as incredibly realistic. Maybe someday every dev will have tons of free time and we’ll all get together and work on it. I’ve had managers who apparently thought that would happen. But I’d bet $1000 to anyone that it will be the same in 5 years.
If there is a Home Assistant 2.0, some concept of RBAC needs to be there from the beginning, as well as sandboxed storage for integrations, and a concept of secure storage for integration credentials. If not RBAC, then at least a guest role or non-admin user. The other two are so basic that any web developer who allowed something like that would be fired for negligence or incompetence.
(this is from 2009 btw - this is hardly state of the art, and before most of us used the internet to manage most of our lives)
OK, now imagine instead of being in a database that is password protected, it’s just sitting in a file on a computer with no restriction. Sure, you’re HA instance is password protected - but not to any integrations. They’re right inside with no restriction. And lots of people have their iCloud credentials in there, possibly Google, who knows what else. Potentially any service you’ve ever logged into HA with. At minimum it would be great if there was a ‘safer’ way for integrations to store these things, but there’s nothing so they’re mainly just dumped into a file that any user can trivially access.
Oauth tokens ARE credentials. They are a step in the right direction but integrations have no standardized “secure” way to store them AFAIK (I would love to be wrong) so they’re probably just dumped into a file somewhere too.
I’m fully aware that the application needs them decrypted in memory to make the http requests, and that security is a shell game of hide the token to unlock the token that decrypts the token. That’s still better than being able to simply grep the filesystem for oauth and send every matching file to your cloud instance. People can get through the door at your home, but you still have a door, and you might even lock it at night.
What does ‘accessible’ mean? Read the data? Update it? Add a new one? Should a role be able to move something to a different room? What about change the display name? What about hide or show it? What if there is sensitive data, like tracking someone’s location? Is that fine because it’s read-only? When you consider automations it gets even more fuzzy. If you can add edit an automation to turn on a light, can you also make the doors unlock whenever you want? Can you edit the automation that triggers an alarm to make it do nothing? How does the permission system work with services? How do template manage to function, since it feels like being able to edit any template anywhere gets you pretty close to admin access.
When you get into the real life details, it ends up being a bit more complex than “can role X access object Y”. It took me about 30 seconds to think of those examples. Those are the obvious ones. I don’t even have any idea what might be possible in HA, and the chances of closing off every loophole are…not in the favor of security.
And like I said above, all of these changes will break basically every integration, card, component, template, etc. It’s unavoidable because all of those things need to be designed with the security model in mind or the security might as well not exist.
I would love it if Home Assistant has a rewrite from scratch some day and at minimum makes it possible for this stuff to happen. It needs to be there day one, and it needs to support all of the needs for integrations, templates, components, etc. It can be opt-in for 3rd party stuff, but the core OS should use it to ensure it’s reliable and usable. Outside of that, just be careful what you install and what you type into those text fields.
<3 Home Assistant. There is no way I’d run this if it wasn’t such an awesome tool.
There isn’t any concept of a dashboard being “owned” by a user AFAIK, or entities being restricted by user at all. If you disable a non-admin from calling services entirely, I’m not sure how useful HA is since I believe they couldn’t even turn on lights or use most buttons on dashboards. could be wrong, but that’s kinda the rub here. How do you limit users in a way where it’s not just them looking at a non-interactive webpage but not allow them to perform any arbitrary action.
I probably oversimplyfied things here, I am far from being an expert in this field. What I wanted to say is that the credentials for 3rd party APIs have to be decrypted to be used so there is always a way to get them. Most installations are probably accessed using http so it shouldn’t be too hard to gain access to other account.
Of course credentials should be stored more secure but in the end you shouldn’t give someone you don’t trust access to your network.
Regarding RBAC: Of course there are a lot of things to consider but it shouldn’t be the task of the integration to handle those things. The examples you listed are in my opinion all tasks of the core, not something an integration should handle. The integration provides entites, the core decides who can view them, who can interact with them etc.
Of course there are exceptions like integrations that provide their own UI (cards or even their own panels) but also they should only use some kind of API that already takes RBAC into account.
Again, I am probably oversimplifying things and I don’t know much about HAs internals so I might be completely wrong here. But I personally don’t see RBAC as something thats not possible anymore.
I suggest to start with a simple Role Based access with 3 Roles:
Long term a fine grained access per User could be implemented.
Any integration that provides entities will need a way to tell the RBAC system how to manage permissions for those entities, at minimum. Is this a public, safe entity like the state of a temp sensor? Is this a highly secure and restricted entity, like something that allows you to read files from the file system?
Same for actions. Does this action turn on and off a light? Or is it an action that allows you to install new integrations directly into home assistant?
Integrations would need to provide metadata about the resources (entities, actions) they provide to HA, so permissions can be granted accordingly. Otherwise any system will be either pretty useless, or trivial to bypass. Likely both for a while.
An entity already has some of these informations. It has an area, a device, a label, a domain etc.
So without any changes in the integration RBAC would already be able to limit access for a whole integration, domain, area or device as well as for every entity with a specific label. With labels you could even create rules like all of {n} labels or one of {n} labels.
Of course more meta data allows more rules whihc makes it easier to limit access on groups of entities instead of single entities.
The “Midyear 2024 Roadmap” addressed the need for RBAC as one of 7 key areas of developement but timed it for “later”.
Now we are one year “later” and the 2025 roadmap still mentions improving user control without giving any timeframe.
From what I understand not much has happened in these last 12 months when it comes to RBAC. Does anyone know if this is actually under developement and if we can expect anything anytime soon?
Development takes time, we are not at the next phase yet (phase that includes access control)
Thanks for your reply! I full well know dev takes time and that timeframes can shift.
Reading the introduction to roadmaps I clung to the line “In general, a current priority is about three months, next is another three months after what’s current is done, and so on.” Together with the titel labelling it as the 2024 roadmap I was very much hoping to see something being released between end of year and nine months from posting. That is why I was a bit surprised to see RBAC still just in second priority one year later.
Would be great if there was some kind of updates on how the jurney towards these milestones is coming along - just so people can manage their expectations.
This is an extremely long thread, so if you are asserting that some flavor of RBAC is currently possible, can you please articulate specifically what elements have been discussed that lead you to this conclusion?
What has happened is lots of handwaving, discussion, many opinions expressed, lots of reasons it’s hard have been expressed, and lots of argument between those who seem to think it doesn’t belong in the product and those who think the product is useless without it. (I’m in the latter camp).
In terms of real or meaningful progress, pretty much nothing.
Yes. I understand that this is a community-driven project, but without RBAC Home Assistant will never rise to its full potential. I work in real-estate and HA would be an extremely powerful tool for facility services and property management - but as long as there is no RBAC, this is not an option.
It really is baffling to me, what features (voice, AI) are being worked on, while an absolutely basic, critical feature like RBAC is being omitted.
Really hoping for this to happen soon!