SoylentNews is people
SoylentNews
from the I-need-a-new-IoT...-and-make-it-Snappy! dept.
Submitted via IRC for TheMightyBuzzard
Snappy, a software deployment and management system designed by Canonical for the Ubuntu operating system, could be a shortcut to building trusted IoT applications.
The first rule of building a secure and feature-rich ecosystem is software management — push and pull software updates and software discovery through an app store mechanism from a trusted source.
In the go-to-market IoT race, though, that often doesn't happen. Many Internet of Things (IoT) product developers have ignored the traumatic early history of Microsoft Windows, Android and web platforms, and expoits of IoT devices — because software updates have not been designed in — are regularly reported.
Those earlier platforms have been hardened, updates have been automated, and the app discovery and installation have been made trustworthy. IoT developers need to follow their lead.
Snappy, a software deployment and package management system designed and built by Canonical for the Ubuntu operating system, could be a shortcut to building a trusted IoT application.
The Ubuntu-Core required to integrate Snappy software management system uses 612MB, and snapd, the endpoint software management service needed to interact with Snappy, uses 15MB. The IoT device would need 627MB-plus memory for the IoT app called a snap. Because of memory and computational constraints, it is not a solution for ultra-low-power, small memory microcontroller devices but would work with 32-bit devices like the Raspberry Pi. Nevertheless, a review of Snappy is worth the time because it clearly explains a fairly complete approach to the problem of trusted software management and distribution.
(Score: 5, Insightful) by Arik on Friday August 25 2017, @09:26AM (4 children)
Really? Tell me more.
"The first rule of building a secure and feature-rich ecosystem is software management — push and pull software updates and software discovery through an app store mechanism from a trusted source."
Oh fsck off.
"In the go-to-market IoT race, though, that often doesn't happen. Many Internet of Things (IoT) product developers have ignored the traumatic early history of Microsoft Windows, Android and web platforms, and expoits of IoT devices"
Giving you the benefit of the doubt...
"— because software updates have not been designed in — are regularly reported."
No. No, no, no.
The whole centralized push pull app store thing is not about security, and it doesn't give you security. It's about vendor control, it's about making the customer into the product. A properly secure product would NEVER permit updates without user approval, nor would it need to. So the game is, rush to market with insecure product, pretend it's impossible to produce secure product, compromise product further to allow automatic updates to patch security holes, use updates to continuously expand the reach of your spying on your own customers, profit!
And a secure product is nowhere on the roadmap, how would they ever turn that into a steadily increasing income stream?
If laughter is the best medicine, who are the best doctors?
(Score: 2) by nobu_the_bard on Friday August 25 2017, @03:00PM (1 child)
Requiring the user to confirm the updates is as good as not having updates for the 95% of the customers who will never apply them.
(Score: 4, Informative) by Arik on Friday August 25 2017, @06:12PM
If laughter is the best medicine, who are the best doctors?
(Score: 2) by gidds on Sunday August 27 2017, @09:55AM (1 child)
Several points here:
* How would the user approve an update to a light-bulb? Or a thermostat for the heating system? Or an electricity meter? Or a fridge?
* How would an ordinary user (not a computer-literate person like most of us) know whether to approve an update, even if they could? How could they make an informed decision? (Even for those of us here, would we want to spend the time and effort researching every update for all the tens or hundreds of different devices that the connected home will eventually have? For example, I counted 75 devices in my home with a microprocessor, of which 8 have WiFi or Bluetooth; for many people, both numbers are likely to rise a lot.)
* How could user approval be given fast enough? I'd guess that IoT devices are more likely to be permanently-on, permanently-connected, and operating autonomously — which means that malware would spread far faster through them than through computers and smartphones that need to wait until they're turned on, connected, and interacted with. Yet even if an IoT device had a way to request and wait for approval from a user, that would probably take much longer than for a computer or smartphone. So malware would spread much faster than it could be patched out, making the updates mostly useless.
* How could the fabled ‘properly secure product’ exist? It's prevented, not just by market forces (though those certainly aren't helping), but also by the complexity of what we require from it. AISI, NASA can write software with very few bugs, not just because they have orders of magnitude more time and staff than anyone else can afford, but also because their requirements are very specific, very fixed, and (compared to today's general-purpose computing) very limited. (And even then, they allow remote updates, even across billions of miles.)
Bug-free software is hard, and today's software is simply too complex, and interacts in too many different ways, for that to be practical. That's why we need the ability to fix it after production, when problems become apparent.
It's true that disallowing automatic updates could prevent unwanted new ‘features’; however, it would also leave the device open to newly-discovered vulnerabilities, which could lead to the removal of all features, or the addition of even-more-unwanted ones. The real problem here is how to get the one without the other — and that's a social problem, not really a technical one.
There may be technical aids to it, of course. For example, how about building in a series of unit tests, and rejecting any future update which causes a test to fail? Theoretically, that could prevent changes in functionality, while still allowing fixes. However, that just shifts the problem: no set of unit tests is complete, so there would always be loopholes through which new functionality could be introduced. And sometimes tests themselves have bugs; a faulty test could prevent a software bug being fixed. (You could, of course, allow the tests to be updated, but then we're back where we started…)
So who does get to define what counts as a bugfix, and what's a new feature??
[sig redacted]
(Score: 2) by Arik on Monday September 04 2017, @08:27AM
Why should a user *need* to approve such an update?
If there is sufficient need it will justify the necessary adjustments to provide an interface. (Which could be *extremely* simple, btw, should any of the big players actually desire for it to exist - an obvious idea is for it to default to looking for a user at the normal internal gateway addresses.) IF there is not sufficient need, then they should not be updatable at all.
"How would an ordinary user (not a computer-literate person like most of us) know whether to approve an update, even if they could? "
Oh dear, the "ordinary user" problem.
Again, it's really a straightforward binary choice. You either determine that the hassle involved in providing such an interface is a good business decision or not. Just as you do today. The only difference is that today you're free to take the easy choice, allow yourself to update without user approval. NO. Either create an interface that will permit meaningful user approval, or don't update. If you choose to not update, keep in mind you're still liable, so don't create A GIGANTIC EXPLOIT FACTORY and sell it to unsuspecting customers and then expect impunity.
That's what we have at this point in the game, make no mistake. Everyone is free to distribute the most completely untested and unfit code, in uneditable binary form, free to sell it on the promise they'll one day update it to work properly, free to then create a new revision to be purchased separately rather than a bug-fix that customers who have already paid are entitled to, etc. etc. ad nauseum.
They're also free to forbid the hapless consumer from even trying to 'reverse engineer' what is going wrong with the product they paid for, to forbid fixing it.
In this business environment, where this behavior is permitted and expected, of course nothing else will be on offer.
"* How could user approval be given fast enough? I'd guess that IoT devices are more likely to be permanently-on, permanently-connected, and operating autonomously — which means that malware would spread far faster through them than through computers and smartphones that need to wait until they're turned on, connected, and interacted with. Yet even if an IoT device had a way to request and wait for approval from a user, that would probably take much longer than for a computer or smartphone. So malware would spread much faster than it could be patched out, making the updates mostly useless."
The simple answer is not to make and sell vulnerable devices, or else to estimate and budget for replacements as your shitty code is inevitably exploited. I'm REALLY HOPING that it will turn out to make sense for at least a sustainable part of the market to actually take the first route. I would absolutely love to give anyone that will do this my money.
"How could the fabled ‘properly secure product’ exist?"
Back in the 80s I thought that was the hard part.
In retrospect, I was a fool. That would have been the easy part.
Honestly it's not that hard to produce a syllogism without contradicting yourself and without introducing extraneous elements.
I know, some people seem to find it impossible. But they are idiots that can't navigate to a URL. If you call yourself a computer programmer you shouldn't think it's such a great imposition.
And that is in a nutshell how you produce a properly secured product. You give it logical paths that provide the desired behavior and do not permit any other behavior. I don't know any way to make that simpler. Of course it's easier said than done, so is anything worth doing, but it's not some unobtainable mystical craft it's just basic logic that we should all be thoroughly familiar with!
I'll repeat my example of the garage door opener. It needs to listen for signals, verify the authority of signals received, and if verified act on them. Verification of authority, I assume, can best be done via cryptography at this point. So it needs to listen for signals, verify signatures, then if they are correct act on them.It needs to deal with exactly 3 possible signals, no more, no less, so the first section of logic after receiving a signal should be checking to see it it is one of these 3 valid signals. The signals are; 1) open 2) close 3) report. If it receives a signal which indicates ANY OTHER ACTION it should DISCARD THAT SIGNAL and return to waiting loop. ELSE it needs to verify the signature. This is extremely well trod ground. If the signature fails then it should DISCARD THAT SIGNAL and return to the waiting loop. ELSE it should execute the signal.
Implement the paragraph above faithfully (and without placing it in a system with a second CPU which can act as a hypervisor) and you'll have a *properly secured device.*
Do you understand now what I am saying?
No one will ever offer to sell you such a device at anything resembling a good price as long as 98% of the buying population is perfectly willing to buy a device that spies on you for 14 different intelligent agencies, and 144 different ad agencies, at the same time, for 10% less.
And THIS my friend is why we don't have secure devices. It has less than nothing to do with it being impossible. It's not impossible. It's simple. It's too simple. It's the kind of simple that leaves no opportunities for crooks to profit. And this world is run for the crooks, by the crooks, and of the crooks.
"The real problem here is [...] a social problem, not really a technical one."
Had to clip it a bit but those are still your words and I do agree completely.
;)
If laughter is the best medicine, who are the best doctors?