usenix conference policies
The Loadable Security Module
Chris Wright presented the Loadable Security Module patch. This patch has its roots in the previous kernel summit, where Linus asked for a standard mechanism by which enhanced security regimes could be loaded into the kernel. The LSM patch places about 150 hooks throughout the kernel; each hook, essentially, provides a security module with the opportunity to veto an action by some process.
The LSM interface has been stable for about six months, and a number of security mechanisms have been implemented on top of it. Chris stopped short of saying that it is ready for merging into the kernel, but he did say it's at a point where it needs wider exposure and feedback.
Nobody expressed outright opposition to the LSM patch, which is a good sign for its eventual inclusion. The questions were mostly oriented around performance penalties, code maintainability, and other approaches to security.
In general, the performance cost of the LSM patch is small - 0-2% on lmbench runs. That cost is, of course, not counting the overhead imposed by any particular security regime - it is just the LSM framework itself. So, as a whole, LSM costs little; the big exception is with high-performance networking. Gigabyte Ethernet can suffer by as much as 20%. So there is interest in being able to disable the LSM calls for low-level networking only. (Update: the 20% performance cost, it seems, is an SELinux issue, and is not caused by the LSM framework itself. I'm told the real LSM penalty is closer to 5% - still significant, but not on the same scale.)
The LSM patch is intrusive by its nature - those 150 hooks have to be spread throughout the kernel. The changes are small, however; they consist mostly of a call into the security module and a possible error exit. There was some exploration of possibly less intrusive ways of hooking in security checks: checking at the system call boundary or using ptrace(). But checking in this way is far less efficient, and it is also subject to race conditions that could be used to undermine the security of the system.
The LSM team went away without a great deal of feedback beyond a need to look at the worst of the performance problems. Chances are that LSM will make an appearance sometime in 2.5.
author = {Chris Wright},
title = {The Loadable Security Module},
booktitle = {2002 Linux Kernel Developers Summit (2002 Linux Kernel Developers Summit)},
year = {2002},
address = {Ottawa, Ontario Canada (Summit summary online; no proceedings)},
url = {https://www.usenix.org/conference/2002-linux-kernel-developers-summit/loadable-security-module},
publisher = {USENIX Association},
month = jun
}
connect with us