Hi,
This is a request to add the ability to change the HassOS console password for the root account. Currently it is blank and I’m not finding a method in the forums or documentation to change it. This is a security issue as anyone could connect to the physical console and gain access.
More desire in this thread:
https://community.home-assistant.io/t/change-hassio-base-system-console-root-password/164347
Seems like a fair request. Home assistant is the heart of most people’s IOT setup, that is a lot of access. It makes sense to me to have basic security feature like this available (if not required).
This is only accessible through physical access. There is no reason for adding a password.
If someone has physical access, there is no need to login as root at all. Removing the SD card or whatever media you are using is all that needs to be done.
I’m not sure this is a valid argument against standard best practice to change the password of root.
It is merely to argument to ALSO implemented protected credential storage in the HomeAssistant configuration files.
Besides (not withstanding the above), the media-type does make a difference. If HomeAssistant is ran on a virtual machine (e.g. VirtualBox) with the “disk encryption” option in VirtualBox enabled… then the media itself will give no information.
If you’re running virtual box then you have a user/password for the host running virtualbox
Agree with @BassieXL. This is standard server admin 101 best practice and good housekeeping. That argument would never fly in any organization with the same storage access argument. And with the time it takes to debate risks and what someone could do with physical access it could already be implemented.
To avoid we’re deviating the discussion, I’m not going any further on the side note regarding disk encryption.
The important topic is the ability to be able to change password for root, this is a standard best practice.
That the contents of the machine can be read when the SD card or whatever media is removed is not an argument against that practice.
If you can set a password, then you need to have to have the ability to reset the password, which brings it back to simply having physical access. If you can reset a forgotten password, then anyone with access can do this.
If you are protecting it against a casual curious user who happens to know what to login with, who then knows how to escape the HA CLI to get to the host, and then happens to know where the data is, then this is no longer a casual curious user.
This is a read-only embedded OS more like firmware than a traditional OS. There is nothing you can install or remove. Your access is through docker containers on top of that system, the credentials you use for the services those containers provide (where a recent attempt at increasing security was met with controversy) and the credentials you use for HA.
Encryption would be great. But decrypting has to happen before Home Assistant and everything else starts…this is a problem.
The request here isn’t a way to reset the password if it’s forgotten, the request is for a way to set the console password and have it stick. Preferably without having to have a USB stick in the darn thing for a configuration file.
IMO you’re in the exact same situation you are with any server in the case of a forgotten root password that. You’re going to be jumping through hoops to get that password reset anyway.
The idea that this is only accessible through physical access it the whole point of the request. Installation of a physical instance may mean that there is access to the physical console, but no readily accessible access to the storage.
It’s just basic system administration 101 coming up here.
It’s just odd to me that there is so much security at the app level, forcing SSH with certificates, scanning Have I Been Pwned with passwords and secrets, add on security ratings/protection mode, etc. and then the whole OS hinges on root with no configurable password at the physical console…
Because that’s where the users and user management exist in this system. This embedded appliance (OS) doesn’t have users. It doesn’t have sudo or su.
And yet we’re still asking for a modicum of security for that. Is it so hard to believe that folks running something like this want at least the minimum amount of security that has been around since Linux started!?
It’s been 3 years and you act like this was some oversight. I am unable to explain it appropriately apparently.
Personally, I haven’t been in this community that long. I’ve only been playing with Home Assistant for about 6 - 7 months only now am I looking at the actual embedded. I’ve been running it in a venv as I’ve played with it.
Yes and no. There are many things you can set about the host from the supervisor UI within the HA application. That UI and the APIs which it uses are only accessible to authenticated users on your HA deployment. So if an option like this was added there then physical access would be blocked. The only ways into the host would be:
That doesn’t seem unreasonable to me personally.
I mean tbh, I’d prefer to carefully control who can even get to the HA CLI. You can do quite a lot of damage from there even without escaping to the host.
[EDIT] Oh I get it, we’re talking only about password protecting root account to control who can escape to the host. I guess I would like it if you could password protect even before that. Like I’d like to be able to set a password to even get to the HA CLI with physical access as well.
Additionally on this, with console access you can navigate to /mnt/data/supervisor/homeassistant/.storage and get full access to all the plain text passwords in the config including third party integration accounts. Seems like a major security risk to me and enough to warrant simple password management on the console root account.
I assume you mean secrets.yaml and not .storage
The secrets.yaml is only about sharing and obscuring your config. I really dislike the secrets.yaml file 
A password on the console still doesn’t protect from physical access unless encryption is involved. If I have physical access to a device which requires resetting a root password, I would just google it:
With physical access, all bets are off.
This makes the password an inconvenience at most. The alternative is having a brick that needs to be set up again from scratch whenever someone forgets the password they set for root.
If there were some cloud auth involved, where every HA user registered an account with some service, this could be different. But I imagine there are a ton of HA users who would reject this requirement.
So as far as I can tell, without the encryption it’s a waste. In addition, there are no users on this system to manage, or to switch out to root for in order to allow an installation of something, because you can’t install anything. Root doesn’t do anything here. It isn’t managing anything or anyone.
HA OS didn’t have this vulnerability from earlier in the year to worry about for example:
Because there is no sudo. 
So to give us a root password to make things feel better in our heads, in order to make us further think this is like any other system, is a waste of time. Adding all of this functionality for addressing a physical access situation which can’t be secured because it’s a physical access situation? One could just grab the pi or odroid and put it in their pocket. Even better, remove the SD card and make it look like no one touched it. You don’t have to boot the system to get to the /config directory, you only need something which can read EXT filesystems. No logging in involved.
Encryption is a different beast and a problem because everything needs to be decrypted before HA starts, meaning you would need to enter a password or method to decrypt whenever you restart. That’s why I mentioned this as a challenge earlier. In addition, it would need to be able to work for ALL users of HA and not only those running HA OS. 
Sorry to bump an old topic but I would be interested in the ability to lock the console behind a password as well.
Yes physical access security is highly important but my system runs virtually.
If access to my hypervisor were somehow compromised, they would have console access to Home Assistant CLI without any form of authentication. It’s handing someone another vector of attack to leave any doors open at all.
My rule of thumb is: If it can require a password and/or two factor, make a complex password and enable two factor. Use secure encryption algorithms for all forms of data and communication always.
I don’t care if the system only has access to one empty text document.
Encrypting the disk is not so much an issue when you are running within a hypervisor.
Maybe I’m paranoid but I work in the IT field and have seen what can happen. Elevation of privilege, security vulnerabilities in software, and more. Never believe for a second that something is “secure enough.”
Hello,
sorry to bump this also. I too am interested in this feature.
I’ll try to explain a few points, sorry for this wall of text.
Now I’ll try to explain why we need to have passwords and address some of the previous comments.
First, we need to understand how we evaluate risks. To understand what is a risk, a good explanation can be found here: Threat, vulnerability, risk - commonly mixed up terms - Threat Analysis Group
When evaluating a risk, we need to take into account the asset we want to protect, who / what could try to gain access to this asset, and what is the vulnerability that person/thing could exploit to gain access to the asset. So a risk is an estimation of the probability that someone gains access to an asset though a defined vulnerability. Also, there are 4 ways to address a risk:
(sorry, I am only allowed 2 links, so please replace the “hxxp” with “http”)
source: hxxp://www.pivotpointsecurity.com/blog/risk-tolerance-in-business/
Given our context we could Accept or Mitigate the risk. In our context, we (me, kernelpanic1, etc.) are asking if we could mitigate the risk. Also, evaluating risks gives us a level of criticality for each risk that we can then use to prioritize risks remediation tasks (hint: I am thinking you might be reticent to mitigate this risk because it might be lower in your priorities compared to the rest that needs to be done, which is a completely valid point! Saying it this way is a better answer than trying to explain why it’s not a risk (because it is)).
Note: a mitigation is not a “fix” to a vulnerability, it’s a way to reduce a risk. For example, to protect against the risk of someone using my account, a password is a mitigation. To protect against the risk of someone finding it in some way and then using my password to gain access to my account, MFA is a mitigation.
So now that we understand how to evaluate a risk, we can analyze the risks we have here:
So as we can see, these are 2 distinct risks and they need to be addressed in 2 distinct ways.
And in both of these cases, we can evaluate the effort of mitigating the risk (for example: 8 hour-person for the first one and 32 hour-person for the second one) and decide if the development time is acceptable or not. If not, we can discuss about accepting the risk or if someone has another idea on how we could remediate it.
For the first one, a good and simple (I think) way to mitigate it would be to put a password in place before accessing the HA Cli. Here, I am not an expert in developing HA, so please tell me if my assumption of “adding a password would be simple” is wrong.
For the second one, encryption is definitely a good answer. I am not sure on the complexity. In linux there are multiple ways to encrypt a device and some of them do not need a password to be entered at boot. They would required a TPM-enabled CPU and the TPM package, or that a physical object, like a USB drive or a network share, is connected to the same computer. The advantages of the first one (with TPM) is that you do not need a USB key and you can’t use the drive (the SD card) on another computer (because the TPM would not be the same).
I have experience using the second option where the system boots by reading a key in the USB drive or a network share (see hxxps://fr.wikipedia.org/wiki/Dm-crypt and hxxps://en.wikipedia.org/wiki/Linux_Unified_Key_Setup).
Now the temptation could be high to say that the second option is not good because then someone could simply take the USB key along with the SD Card, but we need to remember that this is a new risk. So the mitigation is still valid, but we introduced a new risk (which, if unaddressed, still makes the system safer):
3. There is a risk of someone with good technical skills (who) gaining access to all information in HA (asset) by taking out the SD Card as well as the USB key and accessing it from another computer (vulnerability)
This third risk has a lower criticality than the second one because the skills needed to use the USB in conjunction with the SD Card are more advanced.
I don’t want to go for another 500 words, but this new risk could also be mitigated in a few ways (physical restrictions, network share, etc.). However, if the option with the TPM is possible, that would be awesome!
Do you think it’s feasible?
Many thanks by the way for the time you put to develop and maintain HA!
There is no security without physical security.
