Some observant folk may have noticed that I’m now listed as the kernel security subsystem maintainer. This came about as a result of the growing number of security projects headed upstream, and recent comments from Linus and Andrew about the lack of a clear security maintainer. In some ways, this is a formalization of the role I’d been performing with the security-testing tree, although of course the workload and responsibility levels will increase.

I’d like to thank Chris Wright, Casey Schaufler and Stephen Smalley for their endorsements and support in this, and I’m expecting that all in the kernel security community will continue forward in a collaborative approach. I consider previous discussions on architecture resolved.

For new security components being proposed for upstream merge, I’d like to generally follow the protocol outlined by Arjan van de Ven and summarized at KernelTrap: Documenting Security Module Intent.

Essentially, any new security project—not limited to LSMs—should be accompanied by a clear and concise document outlining its requirements and expected uses. This is to allow both security and regular folk to perform review of the code in terms of how it meets the specified requirements, and to avoid getting bogged down in unresolvable discussions about the project’s security model.

A good example of how such an approach has helped is with the recent anti-malware scanning project, which rapidly went from zero to hero in a few weeks following elucidation of design goals. The project now has buy-in from several core developers and has led to fsnotify, a unification and overhaul of the various filesystem notification schemes in the kernel.

The design document does not need to be a novel: a page or two should be enough, and certainly as much as you’d expect upstream developers to read first-up.