All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: kernel-hardening@lists.openwall.com
Cc: 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: Thu, 31 Jan 2013 16:10:03 -0500	[thread overview]
Message-ID: <510ADDAB.3010500@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAGXu5jLk6-OHdZP7wQapv1dzK39k8w6ioB_6QtJ5GvP0ZWHzcw@mail.gmail.com>



On 01/31/2013 01:37 PM, Kees Cook wrote:
> On Thu, Jan 31, 2013 at 7:34 AM, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote:
>> In light of events like this http://lwn.net/Articles/535149/ "China, GitHub
>> and the man-in-the-middle (Greatfire)", we are thinking that a guide for
>> securing open source projects is needed.  For example, recommending pull
>> requests or commits be PGP signed are a few things we've discussed that
>> could defend against a MITM attack inserting malicious code.
>>
>> Does anyone have any thoughts as to where we could publish such a guide?
>> Perhaps the Linux Foundation?
>>
>> I believe we have the resources on this mailing list to work through the
>> details and put together a succinct guide that we could take to a wider
>> audience.
>
> Yeah, sounds good. I think we could easily use the kernel-security
> wiki to work on it initially, and if it needs a different home in the
> end, we can move it then.
>
> -Kees
>
> --
> Kees Cook
> Chrome OS Security
>
>
>

Does it make sense to get everyone edit access to the wiki?  If not I 
can set up a page for it and get input from folks here on the mailing 
list as it progresses and update the wiki myself.

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?

-- 
Regards,
Corey Bryant

  parent reply	other threads:[~2013-01-31 21:10 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 [this message]
2013-01-31 23:18     ` Peter Huewe
2013-02-01 14:36       ` Corey Bryant
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=510ADDAB.3010500@linux.vnet.ibm.com \
    --to=coreyb@linux.vnet.ibm.com \
    --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.