All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Peter Huewe <PeterHuewe@gmx.de>
Cc: kernel-hardening@lists.openwall.com,
	Kees Cook <keescook@chromium.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Frank Novak <fnovak@us.ibm.com>,
	George Wilson <gcwilson@us.ibm.com>,
	Joel Schopp <jschopp@linux.vnet.ibm.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Warren Grunbok II <wgrunbok@vnet.ibm.com>
Subject: Re: [kernel-hardening] Secure Open Source Project Guide
Date: Fri, 01 Feb 2013 09:36:21 -0500	[thread overview]
Message-ID: <510BD2E5.1020604@linux.vnet.ibm.com> (raw)
In-Reply-To: <201302010018.52274.PeterHuewe@gmx.de>



On 01/31/2013 06:18 PM, Peter Huewe wrote:
> 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
>
>

Thanks for the input.  Automated patching with Coccinelle and the like, 
and pointers to get folks started with these tools would be a great 
addition.

-- 
Regards,
Corey Bryant

  reply	other threads:[~2013-02-01 14:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-31 15:34 [kernel-hardening] Secure Open Source Project Guide Corey Bryant
2013-01-31 18:37 ` Kees Cook
2013-01-31 19:30   ` Anthony Liguori
2013-02-01 14:33     ` Corey Bryant
2013-02-05 18:34     ` Corey Bryant
2013-02-05 23:09       ` Solar Designer
2013-01-31 21:10   ` Corey Bryant
2013-01-31 23:18     ` Peter Huewe
2013-02-01 14:36       ` Corey Bryant [this message]
2013-02-01 14:17     ` Solar Designer
2013-02-01 14:41       ` Corey Bryant
2013-02-01 15:08         ` Solar Designer
2013-02-05 18:37           ` Corey Bryant
2013-02-06  7:02           ` Shawn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=510BD2E5.1020604@linux.vnet.ibm.com \
    --to=coreyb@linux.vnet.ibm.com \
    --cc=PeterHuewe@gmx.de \
    --cc=aliguori@us.ibm.com \
    --cc=fnovak@us.ibm.com \
    --cc=gcwilson@us.ibm.com \
    --cc=jschopp@linux.vnet.ibm.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kwolf@redhat.com \
    --cc=wgrunbok@vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.