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.
+ Also on Network World: How to improve IoT security +
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.
Snappy and its component source code repositories are available on Github under a BSD-style license. Open source gives added security because the community of developers can look at the code to verify its integrity and absence of malware, and it can be compiled and adapted for devices not supported by Ubuntu. Snapd will run on other Linux distros, but it is dependent on installing Ubuntu-Core in addition to the distro, increasing memory size.
System components and applications are self-contained (except for the most basic OS features, such as network access) read-only images called snaps.
Snappy uses a confinement and security model.
snapcraft.ioSnaps run in a secure storage area isolated from other snaps. Snaps can communicate with one another, automatically or with manually set privileges, to prevent exploits using a consumer and provider architecture. Most interfaces are designed for strong application isolation and user control such that auto-connected interfaces are considered safe, and product design and development teams choose what applications to trust and to what extent by manually connected interfaces.
Unfortunately, Snappy does not support address space layout randomization (ASLR). Ubuntu only supports only ASLR on i386 and AMD64 processors. ASLR is important because it stores executables in system memory by randomizing the addresses, so an attacker using a memory corruption vulnerability cannot predict its location and exploit a function such as escalating privileges.
Ubuntu has a snap store for discovery, distribution and updates. IoT developers are not required to use it. The developer can create their own store with Snappy from which devices can automatically pull updates on a daily basis. Using a simple transactional update system, snaps can also be easily uninstalled or rolled back.
Each snap is delivered as a read-only compressed file, which also needs to be considered when budgeting device memory. The types of updates are kernel, OS, gadget or application snap. The snap optionally can be stored in a common multi-revision, writable space for version rollbacks. Storing multiple revisions needs to be accounted for in the memory budget.
If configured for multiple stored revisions, a snap is updated by storing a read-only image on the device with an incremented revision number on the device. New writable spaces are created for the update, and the previous version’s writable spaces are copied to the new ones. Data in the common space isn’t altered in any way. The new snap is interpreted by Ubuntu-Core to be the current runtime module using a symbolic link.
snapcraft.ioFor updated application snaps, the new versions of user executable applications become available the next time the command is run or when the background application daemon is restarted during the update refresh. Updated kernel, OS, and gadget snaps require the device to boot before the update takes effect.
Putting trust in the Snappy store
The Snappy store concept could be expanded to increase the general trust of IoT apps. It would be like the Windows, Google Play and browser extension stores in which trust in these stores and the update mechanisms have replaced the trustworthiness of individual application developers, creating a higher level of trust in apps acquired from these stores.
For example, the Android Google Play scans newly uploaded apps for malware and performs static code analysis. Machine learning models identify benign code for the signatures of developers associated with malware, alerting a team of security specialists to manually inspect the app and test it with dynamic analysis tools. The Play app on Android phones checks for potentially harmful apps, alerting the user and, in extreme cases, uninstalls the app.
Linux is a robust development environment with a rich development toolchain, and it has been ported to many processor architectures for application execution, giving system designers many computational choices where their systems can run — from Raspberry Pi to the cloud.
Linux requires more computational resources than a designer constrained by the limited power supplied by battery or small solar cells and the inexpensive component cost budget they might be able to afford. It is a valuable review, though, because all designers of IoT devices face the same design and security issues — even the low-cost, low-power microcontroller designs.
Read more: