General security question about community provided edge drivers

Apologies if this is a stupid question. Is the direction of the Smartthings Eco system towards community developed drivers being delivered via channels and therefore the source code is not available to the user?

Is their any plans for Smartthings to ‘certify’ these as being safe?

2 Likes

Hi, @Davec

Your question and concern are completely valid. So, answering to your questions:

The Driver Sharing (sharing drivers through channels) mechanism was designed to avoid copy-pasting installation flows, which at some point led users to frustration going through a long installation process for an unmaintained DTHs.

However, this doesn’t completely override the code distribution, as community developers can opt to share their repositories. But again, this is up to them.


Of course, we’re planning to provide Certification Guidelines for those developers / companies that are willing to distribute their devices as SmartThings Compatible Products, however, on this Beta stage, we’re focusing on the improvement and reliability of the architecture.

1 Like

Thanks. All seems sensible. From a personal perspective I like being able to inspect any code I plan to install on my LAN. -:slight_smile:

2 Likes

I wouldn’t be that concerned about channels published by a manufacturer or a well known developer, but if you don’t want code installed without inspecting it first then you’ll need to setup the CLI and run a command to package/publish/install their code on your hub instead of installing it from their channel.

If you install it from their channel then reviewing the driver code posted to a repository is pointless because it might not be the same code published to their channel and they can push new versions of the driver to your hub at any time.

1 Like

Any chance you can add some sort of notification feature for when a new version of a driver is installed on the hub?

If a developer (or ST) publishes a new version of a driver for something like a water sensor and I see a notification then I can test the device, but if I don’t know it was updated and it has a breaking change then I probably won’t find out about it until it’s too late.

If would also be nice if the hub update release notes included detailed information about changes to the driver base/default code because if I’m not mistaken a change to that code would impact all published custom and built-in drivers using it.

Yep I get that…Not too fussed about drivers from a manufacturer, just not too comfortable with community drivers where I can’t see the code

From a personal perspective I like being able to inspect any code I plan to install on my LAN. -

:laughing: then you probably want to inspect the ST code itself

the notification will arrive not only to you but potentially to thousands of users. And after several iterations, you will be tired to test the version like “fixing spelling in Italian”.

You should not be using free stuff (community drivers) for anything important. Think about it as for insurance.

You shouldn’t use free stuff (community drivers) for anything important. Think of it as insurance

Assume that is a joke? Do you not think it is sensible to be concerned? Installing a Smartthings hub on my LAN was indeed a risk I considered and decided the upside was worth it based on the brand.

I would like to install some drivers built by the community but I have decided the risk is not worth it if I cannot see the code.

Sorry if I am being churlish or lacking a sense of humour, I just think it is important to at least consider the topic of security

which brand? Samsung bought start-up SmartThings and now trying to get rid of costs by selling it to Aeotec(?). So if your LAN would be worth it any of these players can upload anything to a device controlled by rather a small team with now very high code quality.
The code you can not see.

I just think it is important to at least consider the topic of security

Even drivers already published by ST are under http://www.apache.org/licenses/LICENSE-2.0

so I would expect even less guaranties from community

Let’s agree to disagree. I’m not sure you are understanding my position and that’s fine

I do suggest that other readers consider the security risk from implementing any device or code on their network. There are a number of factors to consider and it is ultimately a personal risk decision

Take care

1 Like

Incorrect. Samsung has licensed out the manufacturing/selling of the SmartThings hardware. So far, Aeotec is the only announced partner. The SmartThings platform of software and the cloud is still maintained by Samsung SmartThings.

1 Like

Hi @Davec, I think the concern is valid and we encourage users to exercise caution when installing hubs and installing drivers from developers/publishers you do not trust as “peer-to-peer” channels are not directly audited by SmartThings in any way.

Basic Protections Provided by the Edge Driver Permissions Model

That being said, edge drivers have mitigated risk in a few ways:

  1. Drivers must declare permissions and we plan to make these permissions more user visible at install. Unless a driver requests “lan” permissions, it cannot interact with APIs to talk to devices on the local area network.
  2. In the future (not implemented at present), updates will not be able to increase their permissions set. That is, a developer who attempts to publish a driver update to the channel that adds permissions will be prevented from doing so.
  3. Within a permission, we prevent device cross talk. A zigbee driver may only send ZCL messages addressed to device short addresses from the set of devices associated with that driver. Same for Z-Wave. LAN is harder to restrict but we do enforce CIDR ranges that prevent drivers with the “lan” permission from directly phoning home to internet addresses.

Thoughts on Developing Community Trust

I expect and am planning to reach out to established community developers over time to encourage the development of a few somewhat more centralized Open Source projects with observable publication pipelines which might serve as a somewhat reliable source of drivers assuming a good set of maintainers in the community (possibly with SmartThings engineering support) is identified. This would:

  1. Provide “critical mass” to build out tooling to support CI pipelines to run tests, publish to channels automatically, run code lints, etc.
  2. Allow for a larger set of developers by way of the set of maintainers to ensure that issues get fixed and features get added. With a single developer sometimes life happens, circumstances change, etc. and this leaves the software unsupported. With an active project with several maintainers this is less likely to occur.
  3. Having more quality community drivers in one place reduces fragmentation and makes it easier to find reasonable support (if not supported directly).
  4. Over time with a successful track record, this provides some basis for trust.

Other Notes

If we do find malicious drivers published and shared on the community we will take actions to protect users and otherwise deal with the bad actors. In addition, I will submit an internal feature request that would allow for developers to opt into providing the source for their drivers and additional metadata such as a Github page for channels and drivers as I think that would be very useful and follows the same sort of pattern seen in some other packaging ecosystems.

We do believe that having a closed source model will be something that is desired for some manufacturers and community developers but definitely do want to do what we can to encourage auditable patterns of sharing work.

3 Likes

Good post, Paul. I’ve been watching this topic with great interest, as I have been providing, and would like to continue to provide, Edge drivers to the community. But I can empathize with David’s concerns, particularly as it pertains to drivers with LAN permissions.

You mentioned there are already some limitations on the CIDR ranges. Indeed I wondered if a driver would be allowed to post to an internet address and found that you cannot. While that prohibits some otherwise interesting possibilities, I definitely can understand it.

Here is a thought: perhaps there needs to be a mechanism to further limit the IP addresses that a LAN driver can access. Maybe have a configuration somewhere that defines which local subnets or IP ranges are allowable. There are always clever ways to defeat these limitations outside of the hub, but at least as far as the Edge platform is concerned, there would be full visibility and control for the user.

To go a step further, you could also publish a guide regarding ‘safe’ network configuration as there are certainly ways to securely fence hub access within your home network. It may be beyond most users’ capabilities, but for those that are serious about it, they’ll be armed with the right information.

3 Likes

Thanks for this response. Very helpful and reassuring.

I fully understand this, however I personally hope that the majority of community developers opt for the open source model. It will be interesting to see it all plays out

Hi,

Apologies for resurrecting this subject. Can anyone confirm whether there has been any change in how the closed source model is going to work? ie any progress on the below points from the thread?

I have to say, from my perspective things are not looking good. Another, potentially unintended consequence is we are seeing people who are keen to pursue an open-source model dissuaded from doing so as they are perceiving that the closed source crowd are simply consuming other contributions for their own benefit

Obviously, most people don’t seem to care, just seems a pretty sad state of affairs. The limited support from SmartThings staff coupled with the still messy documentation doesn’t help either.

I’ll give it another few weeks to see if I can come up the learning curve so that I can support myself, otherwise I guess I’ll wish you all lots of luck and move to a different solution.

2 Likes

I too am keen to know about it. What I see in community right now is end users are just installing popular edge drivers provided by some community developers. They are just happy with tons of features coming for “free” with no way to ascertain whats going on behind the scene! If its a community help then why not be transparent by publishing source code.
I have also seen some developers announcing … no need to go through hassle of publishing drivers through CLI, just install the driver and voila… ok, fair enough and what about people who are willing to go through the hassle for the sake of security?

Well, having said that nothing can be done much about such community developers, but Samsung needs to take a lead on this to protect interests and privacy of end users. If nothing else, then atleast on enrollment page it should mention in bold red something like … Unverified Publisher - Understand the risks before proceeding. Samsung has mentioned this but its burried somewhere deep in one of their articles.

1 Like

IMHO… SmartThings designed it purposefully to be opaque so devs no longer need to expose their code to users, hence making their work more profitable if they so desire. But Apple, Google, and Microsoft app stores vets submitted apps. Some may be more effective than the others under different circumstances, but they make the effort. Due to the channel dist process, SmartThings has the SOURCE CODE (which is way more than Apple, Google, or Microsoft has), but they’re too lazy to vet any of it?!

1 Like

I am not sure who the ‘closed source’ developers are perceived to be, but, whether intentional or not, it is coming across as a spat out phrase.

I actually changed all my current code to all rights reserved today, just in case I accidentally exposed any of it. Even if I had anything worth sharing, which I don’t, the last thing I would do at the moment is to publish source code, open or not, unless it was explicitly meant for demo purposes. I believe when you put source code out there you should look after it, and things are just too frantic at the moment.

To expand on my previous post. I just feel a number of contributors (not just in this thread) seem to be treating ‘closed source’ like a swear word, while championing ‘open source’ even when it doesn’t seem to be strictly relevant to their case. For example, I can perfectly well see the appeal of being able to read the source code, but it doesn’t matter if it is open source or proprietary if reading is all I am doing.

There is absolutely nothing to stop developers making their source available if they want to, and nothing to stop anyone else building their own drivers using it if any licences allow it. There is a bit more to it than there was with DTHs but essentially nothing has changed in that respect. Although I currently have some community drivers in place that don’t follow that model I have every intention to get rid of them and roll my own in future. I may, however, choose to trust certain developers or other sources of drivers. That’s no different to, for example, installing connected services and trusting that the connector apps that gets installed aren’t doing anything naughty.

I do not, however, have any problem with developers not making their source available. That is entirely their business and if users want to use their channels then that is entirely theirs. Is it a worry that end users will do it blindly without regard to the consequences? Perhaps, but they copied and pasted DTHs by numbers so it is nothing new. The biggest worry about the channels is actually the automatic updating of drivers. However even that is not a completely new worry. If anyone is using a custom capability that I created, I can currently accidentally or deliberately break it and there is nothing they can do about it (though proper versioning might help in future).

Is there work to be done still? Yes, definitely. There is no room for complacency. However no one is claiming we have the finished article yet.

3 Likes