I was given 3-5 minutes today to express my thoughts on the future of Linux security. I was the token non-kernel developer in the room, so I wanted to bring a different perspective - security from the point of view of application developers, of users, and focused on recent events. I’m not sure what I said, but here is what I wrote to prepare for the session.
Kudos to Elena Reshetova for doing such a great job leading the panel discussion and keeping the discussion flowing! Kudos also to panel members Dmitry Vyukov, Christian Brauner, Nayna Jain, and Andrew Lutomirski who I count among my heroes for all that they do for Linux security.
LSS Panel Notes
As I mentioned in my introduction, I haven’t worked on the Linux kernel for a very long time, so I am going to focus on three Linux security ecosystem topics. I always enjoy coming to these events and hearing about the latest innovative and sophisticated kernel security mechanisms and it give me a great sense of hope - hope which is then dashed in October during CyberSecurity Awareness month when I find that the state of the art in end user security advice is to tell them not to click on links.
So what am I most worried about when I think about the future of the Linux security? In the past, users relied on distributions to curate open source software. Now that was always an iffy proposition - some distros actively curated sensitive packages, others take all comers with very little curation, but for the most part, the largest distributions were doing at least some level of curation. Now, with the sheer volume of open source code and all of the alternative ways of package delivery, we have lost that curation. In a world where it is unreasonable for users to read every EULA that they agree to, there is no feasible way to expect users (or even developers) to read all of the code that they rely upon.
How do open source communities signal to each other that they take security seriously? The Linux Foundation has attempted to introduce one way of unambiguously signaling via the CII Badging Project. Achieving a badge is one thing and I congratulate all of the projects that have achieved a badge (curl and the Linux kernel became the 5th and 6th projects to gain the gold badge), but the most important aspect of the CII Badging project is that it is a place to have the discussion about what secure development looks like in the realm of open source. That has lasting value beyond the value of a badge.
The second point that I would like to highlight today is about resources available to open source projects for funds for third party security audits. Many of you may be aware of Mozilla’s MOSS program and its associated Secure Open Source program which has funded security audits for software used by Mozilla and the Mozilla foundation, but I’d like to make sure that you are aware of the Open Tech Fund. “The Core Infrastructure Fund supports the ‘building block’ technologies used by digital security and circumvention tools strengthening Internet freedom“. The Core Infrastructure Fund includes the Red Team Fund which works with partners to audit code underlying secure communications technologies. My second wish that I have is that information about these programs become much more widespread and more widely used.
The final aspect of the Linux security ecosystem that I’d like to talk about is that even as Linux is taking over the world and being adopted in safety critical systems to IOT devices to massive cloud infrastructure, knowledge of Linux security is not proliferating as quickly. I’ve seen a real trend in important projects like the MITRE ATT&CK framework come out of the gate with known gaps in Linux coverage and calling for help which is slow to arrive. Review some Dockerfiles and you’ll find horrifying anti-patterns - one recent one pulled PPA keys in plaintext to install non-security supported software. So with great success comes great need. And my third wish is for Linux security knowledge to become much more widespread very quickly - matching the speed of adoption for Linux itself.
Thoughts that didn’t make the cut
While I was considering what to say, I experimented with different thoughts. These are the ones that didn’t make the cut, but which I record here for posterity.
Now the software supply chain is becoming ever more complex each language distribute some modules via their own special processes users exchange software in docker containers and other types of non-OCI containers via Jupiter notebooks and many more ways. Who’s curating the software now? Nobody. Who is scanning this code?
Curl-bash has become somewhat of a meme, a joke - it takes a community effort to go from a common, but insecure pattern to a joke and we need to keep up these types of efforts.
Jupyter notebooks get handed around the threat hunting community with little review. Dockerfiles contain insecure patterns like pulling keys from key servers in plain text and adding random PPAs as apt sources. We have to drive these anti-patterns to the level of jokes and ensure that they don’t propagate.
At the same time that kernel controls are proliferating and becoming more complex, advanced technologies are kind of passing us by. There was a distinct lack of AI topics on the security track. We still rely on Coverity instead of having open source projects that will replace that level of complexity at the same time new projects as they come up in the overheated security space and makes so much more sense to people to have them be close source because they can capitalize on millions of dollars a VC funding rather than putting a cool project into the open source so by and large we are lacking in open source AI solutions for technology problems. We have a ton of expertly labeled vulnerability data sitting in distro repositories waiting for an AI application to use that data to develop a vulnerability scanner.
Likewise operating system security features now are not the key control point most applications are browser-based, for example, webmail and QRadar. Most users spend most of their time in the browser. Browsers are the security control point that is most relevant to most end users nowadays.
It be really cool to see AI built into the operating system to detect anomalies and do graceful degradation rather than hard deny and that way if something like the old rm -rf attack or ransomware mass encrypting files could just be slowed down while on alert was sent to see whether or not this is authorized activity.
I’ll leave you with a riff off of the commonly quoted aphorism - Security is already here, it’s just unevenly distributed. (groan :)