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.
- When we have “Best practices” lists, it’s because experts evaluated that the practices in these lists are must haves. But we make simple lists like these because explaining why we decided to add an item in the list, and not another, would be too complicated and only a few persons would understand them in depth with all the nuances that comes with them. So when someone says “this is admin 101 best practices” or “this is standard best practice” they are referring to these commonly used, recognized and distributed Best Practices lists. In other words, unless you are an expert in security, you should abide by these best practices.
- There will always be another technique to bypass a mitigation put in place. But it’s not because there is a bypass to a mitigation that the mitigation should not be put in place. This is what we call “Defence in Depth”
- You a definitely bringing good points as to “why” or “why not” we should put a password, but you are missing the nuance an expert can bring that explains this “why”. When this nuance and deep understanding is missing, we should abide by the “best practices” lists and recommendations.
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:
- Avoid/resolve the risk (completely eliminate or forego risk)
- Mitigate the risk (reduce the likelihood or impact of risk)
- Transfer the risk (assign or move the risk to a third-party via Cyber Liability Insurance
- Accept the risk (acknowledge the risk and choose not to resolve, transfer or mitigate)
(sorry, I am only allowed 2 links, so please replace the “hxxp” with “http”)
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:
- There is a risk of someone with a little bit of technical skills (who) gaining access to all information in HA (asset) by accessing the unprotected HA Cli (vulnerability)
- There is a risk of someone with no technical skills (who) gaining access to all information in HA (asset) by taking out the SD Card and accessing it from another computer (vulnerability)
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!