Re: [PATCH] doc: self-protection: provide initial details
On Mon, 16 May 2016, Kees Cook wrote: > + Segregation of kernel memory from userspace memory > + > +The kernel must never execute userspace memory. The kernel must also never > +access userspace memory without explicit expectation to do so. These > +rules can be enforced either by support of hardware-based restrictions > +(x86's SMEP/SMAP, ARM's PXN/PAN) or via emulation (ARM's Memory Domains). > +By blocking userspace memory in this way, execution and data parsing > +cannot be passed to trivially-controlled userspace memory, forcing > +attacks to operate entirely in kernel memory. One caveat is that there may be ways to bypass these protections, e.g. via aliased (direct mapped) memory. I'd also note that some platforms have separate kernel and memory spaces, like Sparc. > +To protect against even privileged users, systems may need to either > +disable module loading entirely (e.g. monolithic kernel builds or > +modules_disabled sysctl), or provide signed modules (e.g. > +CONFIG_MODULE_SIG_FORCE, or dm-crypt with LoadPin), to keep from having > +oot load arbitrary kernel code via the module loader interface. Or utilize an appropriate MAC policy. -- James Morris
Re: [PATCH] doc: self-protection: provide initial details
On Tue, May 17, 2016 at 6:26 PM, Jonathan Corbet wrote: > On Mon, 16 May 2016 19:27:28 -0700 > Kees Cook wrote: > >> This document attempts to codify the intent around kernel self-protection >> along with discussion of both existing and desired technologies, with >> attention given to the rationale behind them, and the expectations of >> their usage. > > I've applied this to the docs tree. In the process, I took the liberty > of applying the suggestions from Randy, hope you don't mind... Ah, thanks! I'll send a follow-up. I had a suggestion for another section and a typo fix. -Kees -- Kees Cook Chrome OS & Brillo Security
Re: [PATCH] doc: self-protection: provide initial details
On Mon, 16 May 2016 19:27:28 -0700 Kees Cook wrote: > This document attempts to codify the intent around kernel self-protection > along with discussion of both existing and desired technologies, with > attention given to the rationale behind them, and the expectations of > their usage. I've applied this to the docs tree. In the process, I took the liberty of applying the suggestions from Randy, hope you don't mind... Thanks, jon
Re: [PATCH] doc: self-protection: provide initial details
On 05/16/16 19:27, Kees Cook wrote: > This document attempts to codify the intent around kernel self-protection > along with discussion of both existing and desired technologies, with > attention given to the rationale behind them, and the expectations of > their usage. > > Signed-off-by: Kees Cook > --- > Documentation/security/self-protection.txt | 261 > + > 1 file changed, 261 insertions(+) > create mode 100644 Documentation/security/self-protection.txt > > diff --git a/Documentation/security/self-protection.txt > b/Documentation/security/self-protection.txt > new file mode 100644 > index ..33ad7183a074 > --- /dev/null > +++ b/Documentation/security/self-protection.txt > @@ -0,0 +1,261 @@ [snip] > + > +The goals for successful self-protection systems would be to that they would be that they > +are effective, on by default, require no opt-in by developers, have no > +performance impact, do not impede kernel debugging, and have tests. It > +is uncommon that all these goals can be met, but it is worth explicitly > +mentioning them, since these aspects need to be explored, dealt with, > +and/or accepted. > + > + > + > +What remains are variables that are updated rarely (e.g. GDT). These > +will need another infrastructure (similar to the temporary exceptions > +made to kernel code mentioned above) that allow them to spend the rest > +of their lifetime read-only. (For example, when being updated, only the > +CPU thread performing the update would be given uninterruptable write uninterruptible > +access to the memory.) (add to spelling.txt ?) > + > + > + > + > +To protect against even privileged users, systems may need to either > +disable module loading entirely (e.g. monolithic kernel builds or > +modules_disabled sysctl), or provide signed modules (e.g. > +CONFIG_MODULE_SIG_FORCE, or dm-crypt with LoadPin), to keep from having > +oot load arbitrary kernel code via the module loader interface. spell out 'oot' > + > + > +## Preventing Leaks > + > +Since the location of sensitive structures are the primary target for is or locations are > +attacks, it is important to defend against leaks of both kernel memory > +addresses and kernel memory contents (since they may contain kernel > +addresses or other sensitive things like canary values). > + Nice job. Reviewed-by: Randy Dunlap Thanks. -- ~Randy
Re: [kernel-hardening] [PATCH] doc: self-protection: provide initial details
On Mon, May 16, 2016 at 07:27:28PM -0700, Kees Cook wrote: > This document attempts to codify the intent around kernel self-protection > along with discussion of both existing and desired technologies, with > attention given to the rationale behind them, and the expectations of > their usage. > > Signed-off-by: Kees Cook > --- > Documentation/security/self-protection.txt | 261 > + > 1 file changed, 261 insertions(+) > create mode 100644 Documentation/security/self-protection.txt Nice job: Reviewed-by: Greg Kroah-Hartman
[PATCH] doc: self-protection: provide initial details
This document attempts to codify the intent around kernel self-protection along with discussion of both existing and desired technologies, with attention given to the rationale behind them, and the expectations of their usage. Signed-off-by: Kees Cook --- Documentation/security/self-protection.txt | 261 + 1 file changed, 261 insertions(+) create mode 100644 Documentation/security/self-protection.txt diff --git a/Documentation/security/self-protection.txt b/Documentation/security/self-protection.txt new file mode 100644 index ..33ad7183a074 --- /dev/null +++ b/Documentation/security/self-protection.txt @@ -0,0 +1,261 @@ +# Kernel Self-Protection + +Kernel self-protection is the design and implementation of systems and +structures within the Linux kernel to protect against security flaws in +the kernel itself. This covers a wide range of issues, including removing +entire classes of bugs, blocking security flaw exploitation methods, +and actively detecting attack attempts. Not all topics are explored in +this document, but it should serve as a reasonable starting point and +answer any frequently asked questions. (Patches welcome, of course!) + +In the worst-case scenario, we assume an unprivileged local attacker +has arbitrary read and write access to the kernel's memory. In many +cases, bugs being exploited will not provide this level of access, +but with systems in place that defend against the worst case we'll +cover the more limited cases as well. A higher bar, and one that should +still be kept in mind, is protecting the kernel against a _privileged_ +local attacker, since the root user has access to a vastly increased +attack surface. (Especially when they have the ability to load arbitrary +kernel modules.) + +The goals for successful self-protection systems would be to that they +are effective, on by default, require no opt-in by developers, have no +performance impact, do not impede kernel debugging, and have tests. It +is uncommon that all these goals can be met, but it is worth explicitly +mentioning them, since these aspects need to be explored, dealt with, +and/or accepted. + + +## Attack Surface Reduction + +The most fundamental defense against security exploits is to reduce the +areas of the kernel that can be used to redirect execution. This ranges +from limiting the exposed APIs available to userspace, making in-kernel +APIs hard to use incorrectly, minimizing the areas of writable kernel +memory, etc. + +### Strict kernel memory permissions + +When all of kernel memory is writable, it becomes trivial for attacks +to redirect execution flow. To reduce the availability of these targets +the kernel needs to protect its memory with a tight set of permissions. + + Executable code and read-only data must not be writable + +Any areas of the kernel with executable memory must not be writable. +While this obviously includes the kernel text itself, we must consider +all additional places too: kernel modules, JIT memory, etc. (There are +temporary exceptions to this rule to support things like instruction +alternatives, breakpoints, kprobes, etc. If these must exist in a +kernel, they are implemented in a way where the memory is temporarily +made writable during the update, and then returned to the original +permissions.) + +In support of this are (the poorly named) CONFIG_DEBUG_RODATA and +CONFIG_DEBUG_SET_MODULE_RONX, which seek to make sure that code is not +writable, data is not executable, and read-only data is neither writable +nor executable. + + Function pointers and sensitive variables must not be writable + +Vast areas of kernel memory contain function pointers that are looked +up by the kernel and used to continue execution (e.g. descriptor/vector +tables, file/network/etc operation structures, etc). The number of these +variables must be reduced to an absolute minimum. + +Many such variables can be made read-only by setting them "const" +so that they live in the .rodata section instead of the .data section +of the kernel, gaining the protection of the kernel's strict memory +permissions as described above. + +For variables that are initialized once at __init time, these can +be marked with the (new and under development) __ro_after_init +attribute. + +What remains are variables that are updated rarely (e.g. GDT). These +will need another infrastructure (similar to the temporary exceptions +made to kernel code mentioned above) that allow them to spend the rest +of their lifetime read-only. (For example, when being updated, only the +CPU thread performing the update would be given uninterruptable write +access to the memory.) + + Segregation of kernel memory from userspace memory + +The kernel must never execute userspace memory. The kernel must also never +access userspace memory without explicit expectation to do so. These +rules can be enforced either by support of hardware-based restrictions +(x86's SMEP/SMAP, ARM's PXN/PAN) or v
