Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 31 Jan 2013 16:10:03 -0500
From: Corey Bryant <coreyb@...ux.vnet.ibm.com>
To: kernel-hardening@...ts.openwall.com
CC: 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



On 01/31/2013 01:37 PM, Kees Cook wrote:
> On Thu, Jan 31, 2013 at 7:34 AM, Corey Bryant <coreyb@...ux.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

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.