Thanks to all of those who participated, and to all the events folk at Linux Foundation, who handle the logistics for us each year, so we can focus on the event itself.
As with the previous year, we followed a two-day format, with most of the refereed presentations on the first day, with more of a developer focus on the second day. We had good attendance, and also this year had participants from a wider field than the more typical kernel security developer group. We hope to continue expanding the scope of participation next year, as it’s a good opportunity for people from different areas of security, and FOSS, to get together and learn from each other. This was the first year, for example, that we had a presentation on Incident Response, thanks to Sean Gillespie who presented on GRR, a live remote forensics tool initially developed at Google.
Overall, it seems the adoption of Linux kernel security features is increasing rapidly, especially via mobile devices and IoT, where we now have billions of Linux deployments out there, connected to everything else. It’s interesting to see SELinux increasingly play a role here, on the Android platform, in protecting user privacy, as highlighted in Jeffrey Vander Stoep’s presentation on whitelisting ioctls. Apparently, some major corporate app vendors, who were not named, have been secretly tracking users via hardware MAC addresses, obtained via ioctl.
We’re also seeing a lot of deployment activity around platform Integrity, including TPMs, secure boot and other integrity management schemes. It’s gratifying to see the work our community has been doing in the kernel security/ tree being used in so many different ways to help solve large scale security and privacy problems. Many of us have been working for 10 years or more on our various projects — it seems to take about that long for a major security feature to mature.
One area, though, that I feel we need significantly more work, is in kernel self-protection, to harden the kernel against coding flaws from being exploited. I’m hoping that we can find ways to work with the security research community on incorporating more hardening into the mainline kernel. I’ve proposed this as a topic for the upcoming Kernel Summit, as we need buy-in from core kernel developers. I hope we’ll have topics to cover on this, then, at next year’s LSS.
The committee would appreciate feedback on the event, so we can make it even better for next year. We may be contacted via email per the contact info at the bottom of the event page.