In this blog post, Linux kernel developer Tom Hromatka talks about becoming a co-maintainer of libsecccomp, what it means and his recent presentation at Linux Security Summit North America 2019.
Recently I was named a libseccomp co-maintainer. As a brief background, the Linux kernel provides a mechanism - called SECure COMPuting mode or seccomp for short - to block a process or thread's access to some syscalls. seccomp filters are written in a pseudo-assembly instruction set called Berkeley Packet Filter (BPF), but these filters can be difficult to write by hand and are challenging to maintain as updates are applied and syscalls are added. libseccomp is a low-level userspace library designed to simplify the creation of these seccomp BPF filters.
My role as a maintainer is diverse and varies greatly from day to day:
I initially started working with libseccomp because we in Oracle identified opportunities that could significantly improve seccomp performance for containers and virtual machines. This work then grew into fixing bugs, helping others with their seccomp issues, and in general trying to improve seccomp and libseccomp for the future. Becoming a maintainer was the next logical progression
Our code is publicly available on github and we also maintain a public mailing list. Most questions, bug reports, and feature requests come in via github. Ideally the submitter will work with us to triage the issue, but that is not required
Pull requests are a great way for others to get involved in seccomp and libseccomp. If a user identifies a bug or wants to add a new feature, they are welcome to modify the libseccomp code and submit a pull request to propose changes to the library. In cases like this, I will work with users to make sure the code meets our guidelines. I will help them match the coding style, create automated tests, or whatever else needs to be done to ensure their pull request meets our stringent requirements. We have an extensive automated test suite, code coverage, and static analysis integrated directly into github to maintain our high level of code quality. These checks run against every pull request and every commit
Periodically we release new versions of libseccomp. (At present the release schedule is "as needed" rather than on a set timeline. This could change in the future if need be.) We maintain two milestones within github - a major release milestone and a minor release milestone. Major releases are based upon the master branch of the repo and will contain new features, bug fixes, etc. - including potentially major changes. On the other hand, the minor release is based upon the git release-
Of course, I get to add new features, fix bugs - and hopefully not add any new ones :), and add tests
And finally I work with others both within Oracle and throughout the greater Linux community to plan libseccomp and seccomp's future. For example, Christian Brauner (Canonical) and Kees Cook (Google) are interested in adding deep argument inspection to seccomp. This will require non-trivial changes to both the kernel and libseccomp. This is a challenging feature that has significant security risks and will require cooperation up and down the software stack to ensure it's done safely and with a user-friendly API
In August my co-maintainer, Paul Moore (Cisco), and I attended the Linux Security Summit (LSS) conference in San Diego. We presented a tutorial on the "Why and How of libseccomp"
Paul opened up the 90-minute session with an entertaining retelling of the history of seccomp, libseccomp, and why it has evolved into its current form. I took over and presented the "how" portion of the presentation with a comparison of white- vs. blacklists, common pitfalls like string filters and parameter filtering.
But the bulk of our tutorial was how to actually write a libseccomp filter, so with a tremendous amount of help from the audience, we wrote a filter by hand and debugged several troublesome issues. Full disclosure: I wanted to highlight some of the challenges when writing a filter, but as Murphy's Law would have it, even more went awry than I expected. Hijinks didn't ensue, but thankfully, I had an engaged and wonderful audience, and together we debugged the filter into existence. The live writing of code really did drive home some of the pitfalls as well as outline methods to overcome these challenges. Overall, things didn't go exactly as I had envisioned, but I feel the talk was a success. Thanks again to our wonderful audience!
The full recording of the tutorial is available here