-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
The Fedora Security SIG is coming back with a new mission and new momentum. Previously the Security SIG concentrated on security responses to vulnerabilities and answered questions from the Fedora community. While this service isn't going away we will be adding two new functions: secure coding education and code audit services.
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid some of the most common mistakes. Our first steps are to document the common causes for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening. Red Hat has started to track a subset of security flaws using Common Weakness Enumaration (CWE) IDs, this needs to be expanded to cover Fedora security bugs. We also have a secure coding guide, the Defensive Coding Guide[0], that is in the works, along with additional documentation.
For code audits, we're really not sure where to start. We want to involve the community in this project, but honestly, we're not totally sure what that means. In the short term we expect to just be more transparent about what sort of work Red Hat is doing in this area and try to make public whatever information we can about code audits; this can be sensitive obviously. If contributors have ideas, or want to help, please join the discussion. This project is expected to evolve substantially over the next few months.
As everyone knows, security is a big deal and keeps getting more important every day. Historically Fedora has done a fantastic job with security, one of the reasons the previous SIG never really took off is because there was no need, Fedora was mostly secure and didn't need fixing. While Fedora ils still secure, there is a lot of opportunity to help. The nature of security is changing very rapidly, technologies like mobile and cloud are changing everything. Rather than sit by and let this happen, we believe Fedora should be out in front, working with the community to ensure open source remains the most secure solutions available.
But don't let what has been said so far become a limit on what can be done. I'd love to start working providing OVAL data, security bulletins, consult when questions arise and more. If you have ideas please join up and lets start working!
You can find us on Freenode IRC in #fedora-security, on our mailing list[1], and in our GIT repository[2].
We look forward to your help.
[0] https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_C…
[1] https://lists.fedoraproject.org/mailman/listinfo/security
[2] https://fedorahosted.org/secure-coding/
- -- Eric
- --------------------------------------------------
Eric "Sparks" Christensen
Fedora Project - Red Hat
sparks(a)redhat.com - sparks(a)fedoraproject.org
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQGcBAEBCgAGBQJR3BEmAAoJEB/kgVGp2CYvcJ8L/RE75c9Ww/B8cNe2pwTBD9yv
6FGfK50QFMlRC6voq2Fd5RZb8Hf+PKoxw4+ewbUYdnN8t0n+DaEvPxP69hJtgJ5N
N1736+aD6OiiArKrdfBO4A9syXfMEmOPsqmye7WuXrripJc8asxu8jrh1DgEjwXk
rFrI2pau3upnzkwRHDTRnMPZ925g3BE7SnHa+UD2KZQ3B29Qos3FHmaX5Kn3LXf+
3h+zNnIVkClGr1HK56QVxgsjNWApIH/HsCspxwOpr3ULKRvWD8FJjVxEyp1EDCrc
Fw0C6Di7hbzM5VNVpg4CUpquoG9QCnbNniF+IEIzcBWHr1MEKSmq64xFhfXFS0Zx
w0wWmDQHmwBYxp+v9FKzuGbyb5YQAkZm7z/wRu1dfL6d39LBzG5y48zIEgmIUL6t
eZX5o+lAc/3/W9sKfBbB0dmEq9m02jTIER96aD8iXNEyU8B6Yr34fnWyTiJ6BmYA
Z0/ZPvq+vRJGl/F+pZkhekm8yYxA+4R8AdUnDwTt1A==
=AU1I
-----END PGP SIGNATURE-----
Hi all,
I'm working through some of my backlog today and came across this fesco
ticket
https://fedorahosted.org/fesco/ticket/1117
Does anyone have any ideas or suggestions? I sadly don't currently have a
ton of time to chase this one.
Thanks.
--
Josh Bressers / Red Hat Product Security Team
Repository : http://git.fedorahosted.org/git/?p=secure-coding.git
On branch : master
>---------------------------------------------------------------
commit fa41f38b864810921f947e08904a299928e80223
Author: Florian Weimer <fweimer(a)redhat.com>
Date: Mon Aug 26 16:15:53 2013 +0200
C: Add material on global variables
>---------------------------------------------------------------
defensive-coding/en-US/C-Language.xml | 46 ++++++++++++++++++++
...ntials-Close.xml => C-Globals-String_Array.xml} | 7 +++-
defensive-coding/src/C-Globals.c | 17 +++++++
defensive-coding/src/src.mk | 1 +
4 files changed, 70 insertions(+), 1 deletions(-)
diff --git a/defensive-coding/en-US/C-Language.xml b/defensive-coding/en-US/C-Language.xml
index 83f6da0..b039ed2 100644
--- a/defensive-coding/en-US/C-Language.xml
+++ b/defensive-coding/en-US/C-Language.xml
@@ -147,4 +147,50 @@
integer overflow.
</para>
</section>
+
+ <section id="sect-Defensive_Coding-C-Globals">
+ <title>Global variables</title>
+ <para>
+ Global variables should be avoided because they usually lead to
+ thread safety hazards. In any case, they should be declared
+ <literal>static</literal>, so that access is restricted to a
+ single translation unit.
+ </para>
+ <para>
+ Global constants are not a problem, but declaring them can be
+ tricky. <xref linkend="ex-Defensive_Coding-C-Globals-String_Array"/>
+ shows how to declare a constant array of constant strings.
+ The second <literal>const</literal> is needed to make the
+ array constant, and not just the strings. It must be placed
+ after the <literal>*</literal>, and not before it.
+ </para>
+ <example id="ex-Defensive_Coding-C-Globals-String_Array">
+ <title>Declaring a constant array of constant strings</title>
+ <xi:include href="snippets/C-Globals-String_Array.xml"
+ xmlns:xi="http://www.w3.org/2001/XInclude" />
+ </example>
+ <para>
+ Sometimes, static variables local to functions are used as a
+ replacement for proper memory management. Unlike non-static
+ local variables, it is possible to return a pointer to static
+ local variables to the caller. But such variables are
+ well-hidden, but effectively global (just as static variables at
+ file scope). It is difficult to add thread safety afterwards if
+ such interfaces are used. Merely dropping the
+ <literal>static</literal> keyword in such cases leads to
+ undefined behavior.
+ </para>
+ <para>
+ Another source for static local variables is a desire to reduce
+ stack space usage on embedded platforms, where the stack may
+ span only a few hundred bytes. If this is the only reason why
+ the <literal>static</literal> keyword is used, it can just be
+ dropped, unless the object is very large (larger than
+ 128 kilobytes on 32 bit platforms). In the latter case, it is
+ recommended to allocate the object using
+ <literal>malloc</literal>, to obtain proper array checking, for
+ the same reasons outlined in <xref
+ linkend="sect-Defensive_Coding-C-Allocators-alloca"/>.
+ </para>
+ </section>
</section>
diff --git a/defensive-coding/en-US/snippets/Features-TLS-GNUTLS-Credentials-Close.xml b/defensive-coding/en-US/snippets/C-Globals-String_Array.xml
similarity index 75%
copy from defensive-coding/en-US/snippets/Features-TLS-GNUTLS-Credentials-Close.xml
copy to defensive-coding/en-US/snippets/C-Globals-String_Array.xml
index 8c28b0f..2f05b7d 100644
--- a/defensive-coding/en-US/snippets/Features-TLS-GNUTLS-Credentials-Close.xml
+++ b/defensive-coding/en-US/snippets/C-Globals-String_Array.xml
@@ -3,5 +3,10 @@
]>
<!-- Automatically generated file. Do not edit. -->
<programlisting language="C">
-gnutls_certificate_free_credentials(cred);
+static const char *const string_list[] = {
+ "first",
+ "second",
+ "third",
+ NULL
+};
</programlisting>
diff --git a/defensive-coding/src/C-Globals.c b/defensive-coding/src/C-Globals.c
new file mode 100644
index 0000000..75b33b4
--- /dev/null
+++ b/defensive-coding/src/C-Globals.c
@@ -0,0 +1,17 @@
+#include <stddef.h>
+
+//+ C Globals-String_Array
+static const char *const string_list[] = {
+ "first",
+ "second",
+ "third",
+ NULL
+};
+//-
+
+// Silence compiler warning
+const char *const *
+get_string_list()
+{
+ return string_list;
+}
diff --git a/defensive-coding/src/src.mk b/defensive-coding/src/src.mk
index 219e70b..d47fc09 100644
--- a/defensive-coding/src/src.mk
+++ b/defensive-coding/src/src.mk
@@ -12,6 +12,7 @@ LDFLAGS = -g
compile_only += C-Pointers-remaining
compile_only += C-Arithmetic-add
compile_only += C-Arithmetic-mult
+compile_only += C-Globals
compile_only += Java-JNI-Pointers
CFLAGS_Java-JNI-Pointers = \