[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 Feb 2013 00:18:52 +0100
From: Peter Huewe <PeterHuewe@....de>
To: kernel-hardening@...ts.openwall.com
Cc: Corey Bryant <coreyb@...ux.vnet.ibm.com>,
Kees Cook <keescook@...omium.org>,
Anthony Liguori <aliguori@...ibm.com>,
Frank Novak <fnovak@...ibm.com>,
George Wilson <gcwilson@...ibm.com>,
Joel Schopp <jschopp@...ux.vnet.ibm.com>,
Kevin Wolf <kwolf@...hat.com>,
Warren Grunbok II <wgrunbok@...t.ibm.com>
Subject: Re: Secure Open Source Project Guide
Hi,
> We should probably start by gathering a list of ideas to include in the
> guide. Some initial ideas that come to mind are:
>
> * Secure programming practices (Secure "Programming for Linux
> and Unix HOWTO" is a good reference for Linux though probably
> out of date)
> * Performing secure code reviews and detecting common
> vulnerabilities
> * Ensuring code is reviewed by trusted parties and proper patch
> tagging is used
> * Signing of releases, pull requests, patches, commits, etc by
> trusted parties
> * Removing vulnerabilities with automated tooling (Static/Dynamic
> analysis, Fuzzing)
>
> Any thoughts?
I'd definitely add
* creating semantic patches out of the secure coding reviews / common
vulnerabilities with coccinelle/spatch.
(Usually the same bugs happen over and over again - see e.g. the CWE list ;)
I know this goes into the direction of your last point, but is not that
trivial to use like e.g. spatch but on the other hand provides "automatic"
fixing.
Just my two cents.
PeterH
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
