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...

[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 -------------------------------------------------- -- security mailing list security(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/security

On 09/07/13 14:33, Eric H. Christensen wrote: > 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... > > [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 > -------------------------------------------------- -- security > mailing list security(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/security > Eric, brilliant idea, especially the secure coding education. There needs to be better guidance on problems, with real examples of code that are wrong, how one can exploit the flaw and what the correct way is to code something to prevent it from being exploitable. This should also include examples of proper logging and graceful shutdown, versus crashing. Also, there should be examples for c/c++, python,php, ruby, or whatever else, makes everyone's boats float.

Sadly, Universities just seem to teach students basics, with no interest in doing it right. This is an appalling state of affairs for everyone in industry/business, consumers and government.

Maybe adding advice on securing services should also be covered.

Also, it would be nice to see more activity on the security list and the channel. Great idea! Thank you, Tristan

-----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... [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 - -------------------------------------------------- -- announce mailing list announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/announce

starting with establishing values and metrics maybe can help - e.g. osstmm rav with scare? I tried to integrate ISECOM´s scare (Source Code Analysis Risk Evaluation) into the Fedora Security Lab, but because scare is licenced cc-by-nd as a software licence we could not. Even if it is not the newest, the Secure Programming Standards Methodology Manual SPSMM is maybe also worth a look. http://www.isecom.org/research/osstmm.html http://www.isecom.org/research/spsmm.html http://www.isecom.org/research/scare.html

On Tue, Jul 9, 2013 at 6:33 AM, Eric H. Christensen < sparks(a)fedoraproject.org&gt; wrote: > 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. SAFECode has recently come out with a training initiative putting secure development material in the public domain: https://training.safecode.org/ - the courses come as templates that may be used/adapted to whatever needs.

There's some good content there - some generic, some Linux-specific - and more coming out soon. They're open to requests and suggestions, perhaps the Fedora SIG would be interested in participating.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQGcBAEBCgAGBQJR3JI+AAoJEB/kgVGp2CYv2igL/RvjbiaJaD70JerlEaexZzho k+lWmj75lHgKkwD/8x80UTPil+1jwD1+gtF2n0mpi5xp1g/NVOhVSWDBsDuSe6D1 z7ZabYD0mvhGaw7/TA26OaSUIHpIR3hRrSBZnUCtiXwC4ubxIpnlUi+tqHzHg3ee YTXq0kilmrLAQioUw7c2Q1gtZLIxse5GT/l4vH2duYHAWY/eURAXbjB5Lldw4JXs nwG3wZCaU/vWsTJliUKNNcvTah0+EYIvv9dhYd3iKgXnyzUdj4PD3UOfRuu7HQ6C SAg/yyHVWfcuWIpk2y4Vbl5NqL3tlt3eDu7YjErCbgMNxpHULn7IN86iQUJSMJlu 5s8hjAvldlPAxtYBDwYiV0dZGwg3KupLQa5s5hbVfjzlauT7Vobq8YtTu320a//o hTQY5HH1jGBjNZIkeGyIANnnI+Sl/aA/2F1KmBP+6LOdHXzvErSIUIru5UtnbTGT xX+vXQNRx3bA4+nHadh6UfGKSXEexSF0gpT4dYbEkw== =5nvw -----END PGP SIGNATURE-----

I'll be the first to declare I am not very versed in the licenses and their sub-types, but the SAFECode FAQ states "All courses are free and published under a Creative Commons license and open, non-commercial usage of the content is encouraged.". Isn't that sufficient?

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQGcBAEBCgAGBQJR3JZ1AAoJEB/kgVGp2CYvV68L+gJ7ILLUkmUxZDD5qpGrSLHI srIdQ+F8t1H4QkfaAgkOIHJdz9q6g+kD99ygHthynBAg7QZMVoKEdGdfwA2GTxsU 1uZtRKLroMkKxnSj5pLhY3V7yuRWfhnPLsU7Cc2JBWZEEVphxhzViP9eZmp4+rBd Wq3D3uOWpxEywASTZIJJJgKm4Y/PSShmOKQHL+8QB/cclsI/PBBPjonB9+iCMRQ0 m16pmIl2vY8fvmKrg9+aFpYfnSKV0JCCzhitl6GDdhQ5CRRBtCjAVJFYsd+ZyAMX c40CL/IQlAo6NK1aGe1jEB6NQSaecVSFoqTITI5qFb5NSQCwZqyn4kNfm+4Sqbvq kKHxWyDeVw9cZmGZMhRWRK1Mz/e+GBxpUD6VVAGuT8ZZwg4XH8RNplSleKSoOiB5 SgrgrYgjPzs1c0mJFspSS4O7RGGvSq9+naQFzBheP1wnz0RYAU/ZF64h6U7TDpYX ctVORQ7TPPQsINiIRWoDHgIaIkHHXso7kdxAHfTqYQ== =b6bd -----END PGP SIGNATURE-----

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.

Eric, do we have a plan to track items like this that probably aren't ready for bugzilla yet?

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQGcBAEBCgAGBQJR3uElAAoJEB/kgVGp2CYvP3kMAIm3vf2NT8Rt6Qjc67StT9ti HILPwapU6MwU9ifvbpjsXEWVZsu4QLaeZ4LrFzG0jrJahxDONvBfdcMbsvZU8wsn j62I0KkBsXn3p/6e7swxZIaLwdyMm7Ta3DKEd2TuBYe80r051HNbG7j3HGsKJ2rU Qpacp3uRIiZoC4a/x4dddP+IaMtYItNW+I7xOHJWsYEFbA2espE/mgQhhvtPtP8h l+MO577+aLlZWdjKBYkHjFqL5M/lVm6WDe/H9gqHgqhnzlM2QhYJxWKLyahnjw9Q 5uIzPJ749J+lo3FIJuXCtTbB/HLl3Vw6qA/dIxvVNAeiGPJDMNqFZN5qvF6NIokp tzq/oo+949PXDPbNzgpZWZ8pd60dOGj9zD1jVcnOm5lszaCNysB3/npsSjcoDAci EWAeMW2D2r/uuMfqO0XRyohbbLB/2YHdqWHzKVDxCFs6BS2NPY4uQTHLpK5HAgV8 u96enm2KXPdFjN1yU6zNUkwh9KxE34mpPisCoAH7zw== =uw+R -----END PGP SIGNATURE-----

On Tue, Jul 09, 2013 at 09:33:29AM -0400, Eric H. Christensen wrote: > 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. Might it be useful to have a ticket system (presumably trac like other things in fedora) and some regular process for going over those tickets?

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGcBAEBCgAGBQJSMKUlAAoJEB/kgVGp2CYv7KsL/jPAPEHGFFvyWUtYTj9muEe7 S64SogA/IfXj71oKq98yn6rtCwvCh/7b6w+WVV43IC2fNHI2KZYExq38VWC7iWnh dNZZ0Din62XvS9zl5n5Z9TcBwpwXL3I8h90/WiPjb6AZQ9knIl2QiPSJR1jMd5ji 9GvM7VaOePuIiObJpGdh39pS2ZWM34MR2XGlF0U5lbFMXm6ukM3LO9XI5BJ7AaWF vR9eJ5MvA8O3LbO4sYA2Yzpdk1s9kYNLOmfYFE1hb/c8DksUaPTsNm2jHZW7e2dF 3mTwLcm/FlrUed+4NwTkXYEwEbt5cyux7Qser0NnXH2Jel1xm1BFQGF8CdWxEscH gk+W4lxBeYTOUropbC06KtDA2O3fkW9L6COQTudEEEn7i/yl9NDaOUgPnsiLV7v5 OLOrJ4nEjGllmtoc6Nl3JPTfxKROrcHLHNN+5UGgJNMnHrsY+6aNWDS7X0lZvI6s dKYETwzVQzQJ08uYf6nnyMvyVie0pWZNgCBVj2kKOQ== =cvmW -----END PGP SIGNATURE-----

On Wed, Sep 11, 2013 at 01:15:24PM -0400, Eric H. Christensen wrote: > I'm not sure how setup it is but we can certainly get that going. Yeah, the important thing is really someone who cares about going over the tickets and prodding them forward (either through IRC meetings or a mailing list review or whatever). Note that I am not volunteering, just saying it would be nice if someone did. :)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGcBAEBCgAGBQJSMKf9AAoJEB/kgVGp2CYvRCsL/158Tjt/c3yM+dt5DqTAbkpd DJKh19PgROGKzCq5UfZIl3htcaus+0Uee82r5/1x95twOqEBdzFqrncDKL2iUV2f rDpWcmWTOohj9fS4fMNyzHeZnSldghdUN3k2Ww54uknAql0kfQ4u7gLTtyjgHcAz r/xGsKOn1eXN6g9rhRF/e4DOyqmgY6x7N+fIfgIcbuSPgOcn3x7fPqUR2BkHyqvo 3wPD79yjna+hMIOgs5/RPOkwGT0EAG3WKDSsEKyqaZDqH6E3Pvr8gyrVgUUVvUt1 HIPlrBJnbX9kSADkCNiRuQyfWaaYY/5Hh20W/AGfZ8HmE83HoK7w7JCF6FbxAa3Z h7mZMvzNP1MJ1ojIxFroNDE33siOwDuckpWce3sUtkq6G3LhpQBHjbJU3zWxL/DT C0aebRBsfwX+eWFiSHBNhm25ifM5epjUJ9Ok7Axv0+9YEKLWlaI3wCqao1HKDiXo GJ5dKasUdUrKIs5LkBHYVMyuZP6zPCy93Op+4EgkSw== =VJ9V -----END PGP SIGNATURE-----

On Wed, Sep 11, 2013 at 01:27:27PM -0400, Eric H. Christensen wrote: > So are we expecting questions or more formal tracking of things we want to > accomplish? I think it would be nice. Otherwise, good ideas come up and then get lost in the shuffle of all the other things we are all working on in Fedora and in other day jobs.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGcBAEBCgAGBQJSMMOUAAoJEB/kgVGp2CYv/z8L/1EErZ0PvYwyLvkonzlwvIjW 9DnvSp7GX5u9f3Z9hMlsXIIAgTGgWqaAbMTem1vgay+wKcL6mqMZDrj2rwZlawQB UXhWCUWD6RXKgmxXF2D9/G5UpC3KHxhc7CQmpUfvVsY24QkHFdv6fbuUsXF8Bd53 RhXutRW5qJNk6F6iZJ2RaH6cWwgtliXWhcfM5VBfDFziV4mssZUJRpjb+9Bek8VX 4W/ZyF88RvQPyfBSCmHG74Bnz+2KUuiNc1dw60edDHJFcoEI2gwlOrUh6J8Vig+N ZJDuJ4iHDkobv6oO7sYKlUAMgcxAM4+ZaZtBwdd/YwVLgTAJGJNnqACeucnHHJR0 O4Tc/jLSiBlCrC8iZa2MrJABlo86dJ+NrtoV6jHNwJrMjLlm0/Rns3D6pmxP4poG yI/VkphYuhNDfd0d+wd0EFQshCXkRph6usy2oXfqnq+FEgpSGVCLh0Hj+EBqnT7v Vt9LjSPWby2YCAn+qspBoQBirb7OOwrTgUzdhYd+CA== =qXQa -----END PGP SIGNATURE-----