"I've put together an automatic system for applying kernel security patches to the Linux kernel without rebooting it, and I wanted to share this system with the community in case others find it useful or interesting," said Jeff Arnold, announcing ksplice. He explained, "the system takes as input a kernel security patch (which can be a unified diff taken directly from Linus' GIT tree) and the source code corresponding to the running kernel, and it automatically creates a set of kernel modules to perform the update. The running kernel does not need to have been customized in advance in any way." The project's website notes, "ksplice cannot handle semantic changes to data structures—that is, changes that would require existing instances of kernel data structures to be transformed." With this limitation, Jeff suggested ksplice is still able to automatically apply 84% of the kernel security patches released between May 2005 and December 2007. He continued:

"I've been pursuing this project because I don't like dealing with reboots whenever a new local kernel security vulnerability is discovered. The rebootless update practices/systems that are already out there require manually constructing an update (through a process that can be tricky and error-prone), and they tend to have other disadvantages as well (such as requiring a custom kernel, not handling inline functions properly, etc). This new system works on existing kernels, and it simply takes a unified diff as input and does the rest on its own."

Patches for a much publicized Linux kernel local root exploit were released today as 2.6.24.2, 2.6.23.16, and 2.6.22.18. The latest bug, labeled as CVE-2008-0600, was introduced by the vmsplice() system call and added into the 2.6 kernel in 2.6.17. It is the third in a series of root exploits surrounding the same system call, the two earlier bugs being CVE-2008-0009 and CVE-2008-0010. Easily obtained exploits exist for both the older CVE-2008-0010 which affected the 2.6.23 and 2.6.24 kernels, and the latest CVE-2008-0600, allowing a local non-root user to gain root permissions.

"This document is intended to specify the security goal that AppArmor is intended to achieve, so that users can evaluate whether AppArmor will meet their needs, and kernel developers can evaluate whether AppArmor is living up to its claims. This document is *not* a general purpose explanation of how AppArmor works, nor is it an explanation for why one might want to use AppArmor rather than some other system," began Crispin Cowan, following Arjan van de Ven's earlier suggestion to document security module intent. Crispin continued:

"AppArmor is intended to protect systems from attackers exploiting vulnerabilities in applications that the system hosts. The threat is that an attacker can cause a vulnerable application to do something unexpected and undesirable. AppArmor addresses this threat by confining the application to access only the resources it needs to access to execute properly, effectively imposing 'least privilege' execution on the application.

"Applications have access to a number of resources including files, interprocess communication, networking, capabilities, and execution of other applications. The purpose of least privilege is to bound the damage that a malicious user or code can do by removing access to all resources that the application does not need for its intended function. For instance, a policy for a web server might grant read only access to most web documents, preventing an attacker who can corrupt the web server from defacing the web pages."

"I'd like to ask you to put a file in Documentation/ somewhere that describes what AppArmor's intended security protection is (it's different from SELinux for sure for example); by having such a document for each LSM user, end users and distros can make a more informed decision which module suits their requirements..." Arjan van de Ven suggested in an attempt to help focus future Linux Security Module discussions on technical issues. He explained, "it also makes it possible to look at the implementation to see if it has gaps to the intent, without getting into a pissing contest about which security model is better; but unless the security goals are explicitly described that's a trap that will keep coming back... so please spend some time on getting a good description going here.." Arjan continued:

"My main concern for now is a description of what it tries to protect against/in what cases you would expect to use it. THe reason for asking this explicitly is simple: Until now the LSM discussions always ended up in a nasty mixed up mess around disagreeing on the theoretical model of what to protect against and the actual implementation of the threat protection. The only way I can think of to get out of this mess is to have the submitter of the security model give a description of what his protection model is (and unless it's silly, not argue about that), and then only focus on how the code manages to achieve this model, to make sure there's no big gaps in it, within its own goals/reference."

A thread on the OpenBSD -misc mailing list began by discussing whether or not XEN had been ported to OpenBSD, "is it planned at some point to release a paravirtualized xen kernel for OpenBSD 4.3 or 4.4?" Later in the discussion it was suggested that virtualization should be a priority for security reasons, "virtualization seems to have a lot of security benefits." OpenBSD creator Theo de Raadt strongly disagreed with this assertion, "you've been smoking something really mind altering, and I think you should share it." He went on to describe virtualization as "something on the shelf, [which] has all sorts of pretty colours, and you've bought it", explaining:

"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."

Later in the thread, Theo went on to note, "if the actual hardware let us do more isolation than we do today, we would actually do it in our operating system. The problem is the hardware DOES NOT actually give us more isolation abilities, therefore the VM does not actually do anything what the say they do." He then suggested that companies marketing virtualization should soften their claims to something supportable, such as, "yes, it [increases] hardware utilization, and the nasty security impact might be low".

"Despite my heart-felt feelings that we should support different people in trying out different things, one of the issues is also that I'm obviously not myself a security person. I can 'decree' all I want, but in the end, I really want the people *involved* to merge security stuff," Linus Torvalds explained during the ongoing discussions surrounding the Linux Security Modules code. He added, "there's the 'core LSM hooks' on one side, but there's also the 'what modules make any sense at all to merge?' on the other, and I really don't have the expertise to make any sensible judgments except for the pure 'process' judgment that we should not hardcode things to just one module!" Linus pointed out that Chris Wright is currently listed as the only LSM maintainer, but hopefully others would step up to help:

"Quite frankly, I do not want to take it over. I really really really hope that people that are interested in security can work this thing out, and my only requirement is that it doesn't end up being any kind of force-feeding of opinions and ideas, since clearly there is tons of room for disagreement in the area.."

"In a nutshell, there is no safe way to unload an LSM. The modular interface is thus unecessary and broken infrastructure. It is used only by out-of-tree modules, which are often binary-only, illegal, abusive of the API and dangerous, e.g. silently re-vectoring SELinux," explained James Morris in an October 17'th commit message converting LSM to be a static interface. Andreas Gruenbacher countered, "LSM can be abused ... so what, this doesn't mean the interface is bad. Non-LSM loadable modules have been known to do lots of bad things, and yet nobody made them non-loadable either (yet)." Linus Torvalds explained that he was willing to unmerge the commit if a valid use for unloadable modules was demonstrated, "I repeat: we can undo that commit, but I will damn well not care one whit about yet another pointless security model flamewar."

Jan Engelhardt pointed to his multiadm security framework which provides multiple "root" users each with unique UIDs as an example of an LSM that benefits from supporting loading and unloading modules. "The use case is so that profs (taking the role of sub-admins), can operate on student's data/processes/etc. (quite often needed), but without having the full root privileges," Jan explained, adding, "this LSM basically grants extra rights unlike most other LSMs, which is why modprobe makes much more sense here.(It also does not have to do any security labelling that would require it to be loaded at boot time already.)" James acknowledged, "based on Linus' criteria, this appears to be a case for reverting the static LSM patch."