Security in Linux
Live Patch
Two competing approaches for live kernel patching have been fused into a hybrid strategy and submitted for acceptance to Linux 3.20 kernel.
Suse's Kgraft and Red Hat's Kpatch both attempt to provide a solution for live-patching a running Linux kernel. Both work in roughly the same way, but are implemented in slightly different fashions. Of the two, Kgraft is being deployed in production right now in Suse Linux Enterprise Server 12; the Red Hat technology is still considered experimental.
A third proposal, a hybrid of the two, was proposed by a Red Hat developer in November of this year. Not only does it fuse ideas from both Kgraft and Ksplice, it accepts patches used by either solution. The beauty of the arrangement is that any existing organization that's made use of either technology won't be left in the cold. There may eventually be a consolidation for the patch format, but it can happen in its own time.
One trend to note is a live-patching's affect (if only indirect) on the rate at which Linux clusters are deployed to allow rolling upgrades, especially in smaller organizations. CoreOS, for instance, aims to make the process of rolling upgrades across a cluster into as automatic a process as possible -- essentially, delivering Linux as a service. The two technologies are likely the be more complementary than competitive, especially if CoreOS remains in the domain of cloud providers rather than behind-the-firewall enterprise installations.
TPM
Selinux
AppArmor
AppArmor ("Application Armor") is a Linux kernel security module that allows the system administrator to restrict programs' capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths. AppArmor supplements the traditional Unix discretionary access control (DAC) model by providing mandatory access control (MAC). It was included in the mainline Linux kernel since version 2.6.36 and its development has been supported by Canonical Ltd. since 2009.
Seccomp
A large number of system calls are exposed to every userland process with many of them going unused for the entire lifetime of the process. As system calls change and mature, bugs are found and eradicated. A certain subset of userland applications benefit by having a reduced set of available system calls. The resulting set reduces the total kernel surface exposed to the application. System call filtering is meant for use with those applications.
Seccomp filtering provides a means for a process to specify a filter for incoming system calls. The filter is expressed as a Berkeley Packet Filter (BPF) program, as with socket filters, except that the data operated on is related to the system call being made: system call number and the system call arguments. This allows for expressive filtering of system calls using a filter program language with a long history of being exposed to userland and a straightforward data set.