Security: Difference between revisions

From Yocto Project
Jump to navigationJump to search
(Created page with 'Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is…')
 
No edit summary
Line 3: Line 3:
We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].  
We are tracking security vulnerabilities in the Yocto Project against the [http://nvd.nist.gov/home.cfm National Vulnerability Database].  


== Security Issues Addressed in Yocto 1.0.1 / Poky 5.0.1 ==


The following security advisories are addressed in the Yocto Project 1.0.1 / Poky "Bernard" 5.0.1:
== Branches that are maintained with security fixes ==


* avahi: CVE-2011-1002
1.7 dizzy (maintainer: Armin Kuster)
* libexif: CVE-2007-6351, CVE-2007-6352, CVE-2009-3895
1.6 daisy (maintainer: Saul Wold)
* libxml2: CVE-2010-4008
1.5 dora (maintainer: Robert Yang)
* openssl: CVE-2010-4180, CVE-2010-4252, CVE-2010-0014
1.4 dylan (maintainer: Paul Eggleton)
* rsync: CVE-2011-1097
master (maintainer: Richard Purdie)
* rsync (GPLv2): CVE-2007-4091
 
* rxvt-unicode: CVE-2006-0126
 
* tar (GPLv2): CVE-2010-0624
== Kernel security patches ==
 
 
Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/
- Linux-yocto; linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Ross Burton)
 
- Vendor kernels
Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/
meta-fsl-ppc (maintainer: xxx)
meta-fsl-arm (maintainer: xxx)
meta-intel (maintainer: xxx)
meta-xilinx (maintainer: xxx)
meta-ti (maintainer: xxx)
 
 
== How to test? ==
If there is any test case for the vulnerability by the upstream project or community; we normally run the test to reproduce the problem and after applying the correction to verify that the problem is solved.
 
If there isn’t any test case and it is complicated and time consuming to write a testcase, we only build the core image for at least two architectures and run the regressions test (ptest) for those branches which have ptest mechanism.
 
 
== Patch name convention and commit comment ==
Security patches should have  reference to the CVE identifier both in the patch file/s and the commit comment.
 
A) Backport of upstream patch (the patch inside poky/meta/recipes- …) Most of the time security patches are backported from upstream project or kernel.org. When backporting a patch, keep the commit comment, signoff etc as it is but add the following:
    1) Add upstream status E.g. upstream “status: backport”
    2) Add CVE identifier in the patch file, use the pattern: Fix-for-CVE-201X-XXXX.patch
    E.g.  poky/meta/recipes-connectivity/openssl/openssl/ Fix-for-CVE-201X-XXXX.patch 
 
 
B) The patch sent to the OE-core (patch file + recipes):
After adding the backported security patch in the  meta*/recipes- */ directory and modifying the yocto recipes, you need to generate a new recipes to send to OE-core or yocto.
This patch/s need also have reference to the CVE/s. Please make sure to add:
  1) The package name in the subject
  2) The reference to the CVE  
 
Example for the commit comment:
-----------------------------------------------
    bash: Fix for CVE-2014-6278
 
    <short description>
 
    References
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
 
    Signed-off-by: <your email addres>
    Signed-off-by: example@example.com
-------------------------------------------------
 
== Some security related links/useful tools ==
 
• CVE details (http://www.cvedetails.com)  
• CVE list, Linux kernel 2014 (http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html)
• Meta-security-layer (https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available)
• Making images more secure (http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure)
• Cvechecker (http://cvechecker.sourceforge.net)
 
 
== Security Issues Addressed in Yocto 1.7 / Poky x. ==

Revision as of 06:55, 11 November 2014

Since the Yocto Project is intended to be flexible and meet the needs of many applications, we leave policy-making decisions around security to our end users. Our goal instead is to ship each release with metadata that follows best practices in that we do not release recipe versions which are known to have significant security vulnerabilities. Generally this is done by upgrading recipes to newer versions that are no longer vulnerable to these issues.

We are tracking security vulnerabilities in the Yocto Project against the National Vulnerability Database.


Branches that are maintained with security fixes

1.7 dizzy (maintainer: Armin Kuster) 1.6 daisy (maintainer: Saul Wold) 1.5 dora (maintainer: Robert Yang) 1.4 dylan (maintainer: Paul Eggleton) master (maintainer: Richard Purdie)


Kernel security patches

Kernel security patches are backported to Linux-yoco kernels regularly from https://www.kernel.org/ - Linux-yocto; linux-yocto_3.10 & linux-yocto_3.14 (maintainer: Ross Burton)

- Vendor kernels Kernel security patches are also backported to Linux-vendor kernels from https://www.kernel.org/

meta-fsl-ppc (maintainer: xxx) meta-fsl-arm (maintainer: xxx) meta-intel (maintainer: xxx) meta-xilinx (maintainer: xxx) meta-ti (maintainer: xxx)


How to test?

If there is any test case for the vulnerability by the upstream project or community; we normally run the test to reproduce the problem and after applying the correction to verify that the problem is solved.

If there isn’t any test case and it is complicated and time consuming to write a testcase, we only build the core image for at least two architectures and run the regressions test (ptest) for those branches which have ptest mechanism.


Patch name convention and commit comment

Security patches should have reference to the CVE identifier both in the patch file/s and the commit comment.

A) Backport of upstream patch (the patch inside poky/meta/recipes- …) Most of the time security patches are backported from upstream project or kernel.org. When backporting a patch, keep the commit comment, signoff etc as it is but add the following:

   1) Add upstream status E.g. upstream “status: backport”
   2) Add CVE identifier in the patch file, use the pattern: Fix-for-CVE-201X-XXXX.patch
   E.g.  poky/meta/recipes-connectivity/openssl/openssl/ Fix-for-CVE-201X-XXXX.patch  


B) The patch sent to the OE-core (patch file + recipes): After adding the backported security patch in the meta*/recipes- */ directory and modifying the yocto recipes, you need to generate a new recipes to send to OE-core or yocto. This patch/s need also have reference to the CVE/s. Please make sure to add:

  1) The package name in the subject
  2) The reference to the CVE 

Example for the commit comment:


   bash: Fix for CVE-2014-6278
   <short description>
   References
   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278
   Signed-off-by: <your email addres>
   Signed-off-by: example@example.com

Some security related links/useful tools

• CVE details (http://www.cvedetails.com) • CVE list, Linux kernel 2014 (http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/Linux-Linux-Kernel.html) • Meta-security-layer (https://www.yoctoproject.org/blogs/andrei-dinu/2013/meta-security-layer-now-available) • Making images more secure (http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#making-images-more-secure) • Cvechecker (http://cvechecker.sourceforge.net)


Security Issues Addressed in Yocto 1.7 / Poky x.