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: 0) by Anonymous Coward on Friday August 25 2017, @08:07AM (1 child)
Let me guess.. includes xorg server, Gnome desktop, browser, VNC software and all their deps.
(Score: 0) by Anonymous Coward on Saturday August 26 2017, @12:13AM
Ah you beat me to it.
I do not think they realize most 'IoT' devices they just went past the total memory (flash and data) on the device by 10-20x. Something along the lines of a raspberry pi is 20-25 a board + another 50-100 bucks worth of external HW. Add in a cell modem and you just doubled the cost again to 200-500. It also needs to be semi robust so you are going to get a bit more cost there. Unless you like getting buried under a mountain of the things.
We usually try to hit less than 20meg for the whole device and even that is 'huge' for a IoT device. We want plenty of reserve memory to hold data instead of OS/app.
Have not dug into it but I hope they put in 'unbrick this'. We spent a good amount of time on our devices to have that capability. The people who will end up resetting an IoT device usually have trouble with a mouse so you need to make it dead easy to reset. As the guy who 'usually does it' is always on vacation *always*.
(Score: 2, Insightful) by Kawumpa on Friday August 25 2017, @08:50AM
From the article:
What is "a consumer and provider architecture?" They are considered safe, not actually safe?
Because those stores are a good idea? And btw, why would I want an application store, or additional software for IoT devices? Aren't they supposed to be appliances? And who out there thinks IoT is a good idea anyway?
What?
(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?
(Score: 2) by kazzie on Friday August 25 2017, @09:31AM (1 child)
Why the heck should my fridge need 627+Mb of RAM in order to not destroy the internet?
Surely we're suffering from code bloat here...
(Score: 3, Insightful) by hendrikboom on Friday August 25 2017, @02:37PM
My fridge doesn't require *any* RAM in order not to destroy the internet,
(Score: 2, Insightful) by loic on Friday August 25 2017, @10:14AM (1 child)
This piece of news just tries to sell you the snappy thing. When you do embedded dev, you put everything at the same low level place as resources as scarce. So we would end up with everything in a single compromised snappy packages, thus defeating its use. Furthermore, a snappy package and its KVM virtualization overhead would be plain stupid for an embbedded device.
Not every frigging device has 700 MB of free space, especially the IoT/embbedded stuff. FYI an arduino UNO rev 3 has 32 KB of flash memory.
(Score: 2) by Arik on Friday August 25 2017, @10:07PM
The thing is there's this CADT attitude that fully understands that many embedded devices today work in those limitations and doesn't care. Because they presume constantly increasing hardware specs, so sure that may be the rev3 but the 4 or 5 or 6 will "grow up" and be able to handle the bloat.
Well first off, increases in hardware specs aren't so reliable as they used to be, a lot of the tech is nearing firm limits. But second, if you're making a single purpose device, it's *undesirable* to have more capability than needed. It's not just low value, it's negative value. I don't care if you can put a GB in the same space as 32kb for the same price, when you're making a garage door opener 32kb is better. Larger process makes it more reliable, it's more than enough memory to do the job, and there's no gain - only potential losses - in giving it more than it needs.
But the manufacturer makes more money the other way. Less robust equipment that requires replacement more often. Plenty of RAM so you can hire a bunch of monkeys to code it in visual basic and still have room for your spyware and adware etc.
In a healthy market the manufacturers wouldn't do this for long, even if they somehow did get in the habit, because customers wouldn't stand for it. But since computers are magic customers don't even understand that they're getting screwed.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by pe1rxq on Friday August 25 2017, @11:03AM
If this is a 'shortcut' to 'trusted iot applications' I am wondering what they where originally thinking of...
This is not internet of thing, more likely they misspelled 'IdiOT'.
(Score: 1, Insightful) by Anonymous Coward on Friday August 25 2017, @11:23AM (2 children)
To whoever wrote that title, FUCK YOU.
(Score: 4, Insightful) by romlok on Friday August 25 2017, @01:13PM (1 child)
Quoting for truth, as a non-AC for visibility.
THIS IS THE EPITOME OF A CLICKBAIT HEADLINE.
Soylent doesn't need this. Don't do it. It only harms the site.
Oh look, now I know at a glance whether this article is something interesting or new to me, or whether I can save myself some time.
(Score: 3, Touché) by Fishscene on Friday August 25 2017, @03:09PM
Where were you folks for this article's headline? https://soylentnews.org/politics/article.pl?sid=17/08/25/0332249 [soylentnews.org] Apparently, Science abandoned someone important.
I know I am not God, because every time I pray to Him, it's because I'm not perfect and thankful for what He's done.
(Score: 3, Touché) by Azuma Hazuki on Friday August 25 2017, @04:10PM (3 children)
See topic. This isn't only stupid, it's ugly, slow, and inefficient. I know aesthetics aren't a moral metric, but it's the dingleberry cherry on top of the crap sundae here.
People, these things are embedded systems. They should be running only tiny distros like TinyCore or Void with a minimal, auditable set of packages from the manufacturer.
I am "that girl" your mother warned you about...
(Score: 2) by fido_dogstoyevsky on Friday August 25 2017, @09:55PM
And, ideally, not an IoT device - hence unstupid, elegant, fast and efficient.
It's NOT a conspiracy... it's a plot.
(Score: 0) by Anonymous Coward on Saturday August 26 2017, @12:26AM
I spent a few years in this segment. Believe it or not there *is* a decent market for customization on the fly sort of app store download like firmware. They all want 'I plug it into a modbus and a can bus at the same time' not that you would really do that.... As you know the space is fairly limited. So a 2 gig distro with 600MB patches are a non starter (especially on dataplans that cap out at 5-50 meg per month). But a 10 meg download and the box suddenly has extra functionality is very appealing.
We spent a lot of time and money on R&D on that exact market segment. The the main company pulled the plug. Not because it was unprofitable (it was doing very well). But that it was not profitable enough and corp politics. Limited hardware SKU was very appealing to IoT re-sellers. Plus it was cool as hell to transform a modbus demo into a gpio pin device in under 30 mins and at min cost and software update. All with the same box. We tried to hit 5MB for the whole thing. Less if we could manage it as even 5MB was too much. This was maybe 3-5 years ago. It was pretty obvious general computing was storming all the way down to the lowest levels. It was not a mater of if, but when.
600+ meg. *sigh* The guys who get stuck with that device will have a nasty surprise when they try to plug it into an AT&T or Verizon. The cost margin will explode and their profits will be gone and the project DOA. Maybe in 5-10 years.
(Score: 2) by Arik on Saturday August 26 2017, @04:10AM
How?
"but it's the dingleberry cherry on top of the crap sundae here."
Now that was an apt turn of a phrase.
"They should be running only tiny distros like TinyCore or Void with a minimal, auditable set of packages from the manufacturer."
Guessing 'void' is similar. TinyCore is a freaking *nix OS. A fully networked, multi-user general purpose OS.
That's STILL WAAAAY too much for a garage door opener!
The more unnecessary junk you stick on these things the less likely they are to be fit for purpose.
A garage door opener needs to do a very limited number of things. It needs to listen for commands, verify the authority of the commands, and then execute the commands. There are three commands it needs to respond to - open the door, close the door, and report the current state of the door. In addition, it needs to have a power-up or boot routine that verifies the presence of all the necessary hardware and sends an error signal if anything is missing.
That's it. That's the devices entire scope. It must do all these things, and nothing else. (Feel free to prove me wrong I'm writing this on the fly after more than a few beers and could easily have forgotten something important - point being it's a very short list of fairly simple tasks; and that while it's important that it do all those things, it's just as important that it do *absolutely nothing else*.)
It doesn't need a multi-user OS, it doesn't even need a multi-tasking OS. The most resource intensive task it should EVER do is to verify the signature when it receives a command, and it's perfectly acceptable for it to completely ignore everything else for at least a MILLION milliseconds while it works on that. Once the command is verified, then the appropriate sequence of actions is taken and it ends with listening to the network for commands again.
Aside from the cryptography, a Z80 with 32kb would be overkill for this. Just how much computer do you need to verify a crypto signature, given a second or even a bit more to do it in?
If laughter is the best medicine, who are the best doctors?