All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Solar Designer <solar@openwall.com>
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:41:55 -0500	[thread overview]
Message-ID: <510BD433.2020803@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130201141705.GA23051@openwall.com>



On 02/01/2013 09:17 AM, Solar Designer wrote:
> Corey, Kees, all -
>
> Why don't we bring this to the oss-security mailing list?  I think this
> topic is not in any way specific nor limited to the Linux kernel.  There
> are ~10x more people on oss-security than on kernel-hardening, and this
> topic is a better fit for oss-security than for kernel-hardening.  There
> is a wiki for the oss-security group, where such content is welcome.
> Anyone can register for an account and edit.
>
> Info on the oss-security mailing list:
>
> http://oss-security.openwall.org/wiki/mailing-lists/oss-security
>
> Subscribe here:
>
> http://oss-security.openwall.org/subscribe
>
> (Of course, Kees and many others in here are already on oss-security as
> well.  Not all, though.)
>
> On Thu, Jan 31, 2013 at 04:10:03PM -0500, Corey Bryant wrote:
>> 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)
>
> CERT's Secure Coding resources are more current, but they're focused on
> programming languages and I think they don't cover operating system
> specific pitfalls (e.g., Linux netlink).
>
>> * 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)
>
> We have some relevant links here:
>
> http://oss-security.openwall.org/wiki/
>
> and more specifically:
>
> http://oss-security.openwall.org/wiki/tools
> http://oss-security.openwall.org/wiki/links
> http://oss-security.openwall.org/wiki/code-reviews
>
> More content (and better organization of content) on the oss-security
> wiki is welcome - including on all topics you listed above.
>
> Thanks,
>
> Alexander
>
>

Thanks Alexander.  I agree, this really is targeting OSS in general so I 
think it makes sense to move to the oss-security mailing list and wiki. 
  Is anyone opposed to this or have a better idea?

And maybe we can find a good place to link to our Linux Security 
Workgroup wiki on the OSS wiki: 
http://kernsec.org/wiki/index.php/Linux_Security_Workgroup

-- 
Regards,
Corey Bryant

  reply	other threads:[~2013-02-01 14:41 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
2013-02-01 14:17     ` Solar Designer
2013-02-01 14:41       ` Corey Bryant [this message]
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=510BD433.2020803@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=solar@openwall.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.