Is the Linux kernel a security problem?
Security is an ongoing issue for all operating systems, including Linux. While Linux has generally had a good reputation compared to Windows when it comes to security, no operating system is perfect. A writer at Ars Technica recently examined the issue of security and the Linux kernel.
JM Porup reports for Ars Technica:
The Linux kernel today faces an unprecedented safety crisis. Much like when Ralph Nader famously told the American public that their cars were “unsafe at any speed” back in 1965, numerous security developers told the 2016 Linux Security Summit in Toronto that the operating system needs a total rethink to keep it fit for purpose.
No longer the niche concern of years past, Linux today underpins the server farms that run the cloud, more than a billion Android phones, and not to mention the coming tsunami of grossly insecure devices that will be hitched to the Internet of Things. Today’s world runs on Linux, and the security of its kernel is a single point of failure that will affect the safety and well-being of almost every human being on the planet in one way or another.
“Cars were designed to run but not to fail,” Kees Cook, head of the Linux Kernel Self Protection Project, and a Google employee working on the future of IoT security, said at the summit. “Very comfortable while you’re going down the road, but as soon as you crashed, everybody died.”
“That’s not acceptable anymore,” he added, “and in a similar fashion the Linux kernel needs to deal with attacks in a manner where it actually is expecting them and actually handles gracefully in some fashion the fact that it’s being attacked.”
The article about the security of the Linux kernel spawned a lively discussion in the comments section and folks there weren’t shy about sharing their thoughts:
Haravikk: “The kernel drivers are the biggest annoyance to me; I know that once upon a time they were picked for efficiency, but it’s been a long time since we really needed them to be loaded within the kernel itself. I mean, the idea of so much third-party code that you cannot test being within the single most important part of your operating system just horrifies me now.
It’s a big problem on OS X/macOS as well; maybe it’s just because I use it more but the quality of Mac drivers very often leaves a lot to be desired, and aside from one time when I had failing RAM, third party kexts have been the cause behind 99.9% of kernel panics I’ve encountered.
Interestingly I’ve never had as much of a problem with this on Linux, but then I mostly only use it in a server environment so it’s probably just not much of a risk in the first place. In fact I’ve had more problems on Windows and that’s the OS I use the least overall; I only use it for gaming yet it seems to find ways to randomly break despite my not changing anything.”
Raxx7: “I think this is a fools errand.
You can’t protect against consumer devices which whose manufacturer has crappy security policies and doesn’t release updated simply hardening the kernel. There are too many other layers of software which can fail and be exploited.
Hardening, sandboxing and etc are not a replacement for good update policies.
We need to legislate that companies are responsible for providing updates to their internet enabled products for X years or something like that.”
Kazper: “Yes and no. Updating is important and you are right you cannot completely prevent security bugs that must be fixed with an update. But you can get a long way by mitigation techniques, and if you can “kill” 80% of all security bugs with a safer driver model and handling that’s pretty important.
It’s not a replacement for updating but it’s a damn good complement given that zero days WILL exist for undetermined lengths of time before even being discovered, much less patched and updates pushed. Even with a mandatory update scheme.”
Amiasc: “When open source started it worked because the users did the testing , this worked when the users where all very technical and where aware of their limitations. We also rely on software in a completely different way now because of societies wider acceptance of computing. This has put the software in the hands of people who do not understand open source.
As usage of open source has expanded the Software Testing of it has not , there are many reasons for this , some being financial , some being technical, there are many of them and their reasons are not really that relevant. The closed source software that open source is competing with has dramatically increased its quality through enhanced development processes and embedding test within its development.
The challenge for the linux kernel is to raise its testing game by defining a large range of test environments and requiring new commits to include tests for those environments. Those tests need maintenance and validation but all of that doesn’t have to be done by the developer, writing tests is a good way to introduce new developers to the kernel.
I do a lot of software testing on linux based products and frequently hit examples of bad quality control in linux , typically the vendors i work with work around it instead of commiting changes, ease of access is a big thing. I wonder if a mechanism where by vendors can be disallowed to use linux in their product if they don’t include an updates system might help.”
Musashi31: “Isn’t this a good argument in favor of micro kernel architecture (with device drivers running in userland), the architecture that Linus found ’stupid.’”
Dfavro: “This is really, sadly, true. It gets depressing reading various vendors’ bugzilla instances and seeing all number of WONTFIXes and such where the issue is being bandied back and forth between upstream, driver maintainers, etc with no fix in sight.
For usability and performance issues, this is annoying, but for security it’s critical. And yes, the problem is updates (or the lack thereof) but that’s a problem that isn’t ever going to get solved because there’s no money in it and no method to enforce control even if there was some kind of financial incentive.
So yes, it probably will mean some significant re-architecting, and hopefully sooner than later such that less insecure devices end up in the field.”
Riddler876: “Moving drivers out of the kernel isn’t a panacea, given the userland program MUST have access to enough of the kernel through the userland API to do its job, if the userland driver is insecure it can still run rampant with that access. That’s not to say moving them out of the kernel wouldn’t solve some significant problems, it would, but its essentially an opinionated argument that the benefits outweigh the drawbacks. According to Linus they don’t, and hey it’s his kernel he can do what he wants with it. Someones free to fork it!
I hate fixing symptoms of problems instead of the problems themselves, from what I see from the arguments root problems here are the badly thought out IoT security landscape and driver writers poorly secured code. Unfortunately, I don’t think we can fix either of those two things in a hurry.”
Bsyp: “The real problem is there are too many competing technologies and protocols. And some/many/most of those companies are garbage and don’t care because their idea of providing updates is to force you to buy a new IoT doorknob to solve the problem. A doorknob should last the life of a house, not the life of the housefly in it.
There should be some sort of open source module, a single technology that talks to all needed devices regardless of manufacturer, that gets updated and continues to work on older devices, and can update itself since it’s connected to the internet. It would also be nice if it was self aware somehow where it could determine it was hacked, under attack etc, and only do one thing: wait for a secure update.”
Passivesmoking: “If kernel drivers suck then maybe it’s time to remove (or at least minimise) them. If I remember right microkernel research showed it was possible to push most if not all drivers into user space, though the performance hit was huge. Has there been any work done on mitigating that performance hit (other than by doing things like putting all the drivers in a service that runs in kernel space and making them effectively kernel drivers again, the way most modern systems that claim to be microkernels actually do)?
I know there’s performance considerations for things like GPUs, but really, does a USB port driver need to shave every cycle it can? ”
Chromebook Pixel 2 gets Android apps
The news that some Chromebooks would get Android apps got quite a lot of attention a while back. Now Google has released Android apps in the Chrome OS stable channel for the Chromebook Pixel 2.
Phil Oakley reports for Android Police:
A few days ago, Google released Android apps to two Chromebooks: the Acer Chromebook R11 and the ASUS Chromebook Flip. These arrived version 53 of Chrome OS, on the stable channel. However, the Chromebook Pixel 2, which has had Android apps in beta up until now, has been waiting for the stable release. This painful period is over, Pixel 2 owners, because you too can now join in on the Android fun with the release of stable Chrome OS 53 to last year’s flagship Chromebook.
From what we can tell, it works the same way as it did on the beta. Simply launch the Play Store app from the app launcher, wait for it to set up, then you should be able to download Android apps from the Store. It is possible, however, that some apps will be buggy, crash, or have missing features, because they were built for phones or tablets, not laptops.
6 open source fitness apps for Android
Speaking of Android, there are some useful fitness apps available that are worth considering if you need to get in shape. And each of them is open source software for your Android phone.
Joshua Allen Holm reports for Opensource.com:
A key part of developing a good fitness routine is creating a solid workout plan and tracking your progress. Mobile apps can help by providing readily accessible programs specifically designed to support the user’s fitness goals. In a world of fitness wearable devices like FitBit, there are plenty of proprietary apps designed to work with those specific devices. These apps certainly provide a lot of detailed tracking information, but they are not open source, and as such, do not necessarily respect the user’s privacy and freedom to use their own data as they wish. The alternative is to use open source fitness apps.
Below, I take a look at six open source fitness apps for Android. Most of them do not provide super detailed collection of health data, but they do provide a focused user experience, giving the user the tools to support their workouts or develop a plan and track their progress. All these apps are available from the F-Droid repository and are all licensed under the GPLv3, providing an experience that respects the user’s freedom.
HIIT Timer
Open Training
RunnerUp
Seven
Styrkur
SWJournal
Did you miss a roundup? Check the Eye On Open home page to get caught up with the latest news about open source and Linux.