[kernel-hardening] Linux Security Workgroup

* [kernel-hardening] Linux Security Workgroup
@ 2012-09-27 19:26 Corey Bryant
  2012-10-02 16:23 ` [kernel-hardening] " Kees Cook
  0 siblings, 1 reply; 14+ messages in thread
From: Corey Bryant @ 2012-09-27 19:26 UTC (permalink / raw)
  To: kernel-hardening, James Morris, Theodore Tso, Kees Cook,
	Paul Moore, Eric Paris, Tyler Hicks, zohar, john.johansen

At the Linux Security Summit we began discussing the Linux Security 
Workgroup and some of the efforts that we can focus on.

The charter of the workgroup is to provide on-going security
verification of Linux kernel subsystems in order to assist in securing 
the Linux Kernel and maintain trust and confidence in the security of 
the Linux ecosystem.

This may include, but is not limited to, topics such as tooling to 
assist in securing the Linux Kernel, verification and testing of 
critical subsystems for vulnerabilities, security improvements for build 
tools, and providing guidance for maintaining subsystem security.

For communication, we have permission to use the following mail list: 
kernel-hardening@lists.openwall.com
The list can be subscribed to at: http://www.openwall.com/lists/#subscribe

If you would like to participate or know anyone else who would like to, 
please join the mailing list or feel free to pass the word on.

The bullets below are further details based on our discussion at the 
Linux Security Summit:

General Notes:
--------------
* The idea of the workgroup came from the Linux Foundation and Ted Tso 
after the kernel.org attack.

* Malicious code wasn't inserted into the kernel tree.  git hashing 
would have detected a mismatch in kernel code quickly.  Also the PGP web 
of trust and kernel signing was an important validation measure that's 
since been taken.

* Guidelines for subsystems could be created to provide guidance for 
best practices to consider when reviewing code (e.g. detecting common 
vulnerabilities, don't leave ssh private keys around, etc).

* Development and maintenance of automated tools would assist in 
securing the kernel on an ongoing basis.

* Maintainers should have more automated tooling available to enforce 
security checks on patches as they come in.

* Daily execution (perhaps on linux-next tree or as part of build 
system) of static analysis and emailing reports out to a list and CC'ing 
authors using git blame.  Red Hat's Coverity license allows results to 
be shared with the upstream project.

* Provide verification of critical kernel subsystems (Kernel build 
infrastructure, Networking, Network file systems, KVM, Cryptographic 
library).

* Fuzz testing could be used to find potential problems in the kernel's 
interface to userspace (syscall, ioctl, KVM paravirt calls).

* More stringent rules could be adopted such as patch signing.

* The security community should share and coordinate their efforts on 
the mail list so that overlap of work items does not occur.

Resource requirements:
----------------------
* We should narrow down the working group's scope and/or priorities 
before we narrow down the resources.

* Perhaps allocating people for a limited amount of time that rotates 
would be the most attainable resource possibility.

-- 
Regards,
Corey Bryant

^ permalink raw reply	[flat|nested] 14+ messages in thread