nelsonic
commented
4 years ago @th0mas thanks for opening this issue. I'm totally for feature flags in principal. Great that you're thinking ahead. 👍
My only question/concern is from a security perspective: "How will a malicious user abuse the feature flags?"
We've always got to consider these questions from a Red Team angle;
Will this help us improve security or help "them" attack us?
If all features are baked into the firmware, does that make it easier for a malicious person to crack it? If they gain access to the
UARTinterface and it's just a matter of flipping bits in the firmware in order to enable certain features, have we just made the hackers life easier by leaving the feature in the firmware but "disabled" by a flag? We are definitely going to benefit from the fact that fewer people know how to interpret/manipulate BEAM bytecode, but we still cannot take it for granted that it cannot be done. From reading https://stackoverflow.com/questions/587996/erlang-beam-bytecode and related links, it appears fairly straightforward. And since all our code will be Open Source on principal, we will be making the attacker's life quite easy as they will be able to run the exact code on their test bench in the comfort of their home/lab. They can create an offline attack and just bring the crack/script with them to @home where they will let themselves in pretty quickly. 🙄
My preferred approach would be a modular one where we end up with separate firmwares. For example, for the "server closet" (which I would still like to use an electronic lock so I don't have to carry a physical key) I want to have the absolute bare minimum code/firmware because it's the highest "stakes" lock in the building.
If a particular piece of functionality is common to every firmware bundle it goes in the "core".
If a feature/function is not core but is reusable, it becomes an independent module with docs and tests.
(we can use git modules in our mix.exs > deps for now, no need for Hex.pm)
If a feature is specific to a particular device, it can be included just in that device's codebase.
LMK if this answers your question or if you need anything else. 👍
th0mas
We need to be able to enable some features on some devices and disable them on others - e.g. The welcome display.
To do this we need some sort of feature flag system, I think we have several ways of doing this.
In #2 I implemented a handshake system, we could extend this to toggling features on and off each device. E.g. We could send a keyword list of flags:
[{lock: true}, {display: true}]to configure the device on startup. This increases our firmware complexity but allows us to have greater flexibility down the line, for example if you want to add a display later thats a checkbox.Compile time flags. We could configure the firmware features using environment variables and only run the necessary parts. This comes with some more complexity when deploying but will result in clearer firmware code. Changing the features of a device will require compiling and pushing a new firmware.
Different firmwares. dwyl/smart-home-security#10 suggests we will have a separate Pi running the display, so we could create and deploy a new firmware. This would reduce filesize but would result in duplicated code, as, for example, we would have to maintain two
HubClients. This is the simplest option as there is no configuration to sort out@nelsonic thoughts?