diff options
author | Michael Opdenacker <michael.opdenacker@bootlin.com> | 2021-08-06 12:33:04 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-08-10 11:29:46 +0100 |
commit | 4c7e3b64bc9cefb05fa4a995e83bb0f90160a9fc (patch) | |
tree | 3af0de4c8c88564f93dfe0346c142f79f1cdfee8 /documentation/dev-manual | |
parent | 23e640b80933760fdfb65ac9f764b93a3cf298b5 (diff) | |
download | poky-4c7e3b64bc9cefb05fa4a995e83bb0f90160a9fc.tar.gz |
manuals: further documentation for cve-check
This adds details about the actual implementation
of vulnerability checks, about how to fix or ignore
vulnerabilities in recipes, and documents the
CVE_CHECK_PN_WHITELIST and CVE_CHECK_WHITELIST variables.
(From yocto-docs rev: 55886d211218b3a604c2f8a29c854685ebf284dd)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reviewed-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/dev-manual')
-rw-r--r-- | documentation/dev-manual/common-tasks.rst | 69 |
1 files changed, 69 insertions, 0 deletions
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst index 7fa0df4d39..37077d72d4 100644 --- a/documentation/dev-manual/common-tasks.rst +++ b/documentation/dev-manual/common-tasks.rst | |||
@@ -11131,6 +11131,75 @@ Enabling vulnerabily tracking in recipes | |||
11131 | The :term:`CVE_PRODUCT` variable defines the name used to match the recipe name | 11131 | The :term:`CVE_PRODUCT` variable defines the name used to match the recipe name |
11132 | against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__. | 11132 | against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__. |
11133 | 11133 | ||
11134 | Editing recipes to fix vulnerabilities | ||
11135 | -------------------------------------- | ||
11136 | |||
11137 | To fix a given known vulnerability, you need to add a patch file to your recipe. Here's | ||
11138 | an example from the :oe_layerindex:`ffmpeg recipe</layerindex/recipe/47350>`:: | ||
11139 | |||
11140 | SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \ | ||
11141 | file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \ | ||
11142 | file://fix-CVE-2020-20446.patch \ | ||
11143 | file://fix-CVE-2020-20453.patch \ | ||
11144 | file://fix-CVE-2020-22015.patch \ | ||
11145 | file://fix-CVE-2020-22021.patch \ | ||
11146 | file://fix-CVE-2020-22033-CVE-2020-22019.patch \ | ||
11147 | file://fix-CVE-2021-33815.patch \ | ||
11148 | |||
11149 | The :ref:`cve-check <ref-classes-cve-check>` class defines two ways of | ||
11150 | supplying a patch for a given CVE. The first | ||
11151 | way is to use a patch filename that matches the below pattern:: | ||
11152 | |||
11153 | cve_file_name_match = re.compile(".*([Cc][Vv][Ee]\-\d{4}\-\d+)") | ||
11154 | |||
11155 | As shown in the example above, multiple CVE IDs can appear in a patch filename, | ||
11156 | but the :ref:`cve-check <ref-classes-cve-check>` class will only consider | ||
11157 | the last CVE ID in the file name as patched. | ||
11158 | |||
11159 | The second way to recognize a patched CVE ID is when a line matching the | ||
11160 | below pattern is found in any patch file provided by the recipe:: | ||
11161 | |||
11162 | cve_match = re.compile("CVE:( CVE\-\d{4}\-\d+)+") | ||
11163 | |||
11164 | This allows a single patch file to address multiple CVE IDs at the same time. | ||
11165 | |||
11166 | Of course, another way to fix vulnerabilities is to upgrade to a version | ||
11167 | of the package which is not impacted, typically a more recent one. | ||
11168 | The NIST database knows which versions are vulnerable and which ones | ||
11169 | are not. | ||
11170 | |||
11171 | Last but not least, you can choose to ignore vulnerabilities through | ||
11172 | the :term:`CVE_CHECK_PN_WHITELIST` and :term:`CVE_CHECK_WHITELIST` | ||
11173 | variables. | ||
11174 | |||
11175 | Implementation details | ||
11176 | ---------------------- | ||
11177 | |||
11178 | Here's what the :ref:`cve-check <ref-classes-cve-check>` class does to | ||
11179 | find unpatched CVE IDs. | ||
11180 | |||
11181 | First the code goes through each patch file provided by a recipe. If a valid CVE ID | ||
11182 | is found in the name of the file, the corresponding CVE is considered as patched. | ||
11183 | Don't forget that if multiple CVE IDs are found in the file name, only the last | ||
11184 | one is considered. Then, the code looks for ``CVE: CVE-ID`` lines in the patch | ||
11185 | file. The found CVE IDs are also considered as patched. | ||
11186 | |||
11187 | Then, the code looks up all the CVE IDs in the NIST database for all the | ||
11188 | products defined in :term:`CVE_PRODUCT`. Then, for each found CVE: | ||
11189 | |||
11190 | - If the package name (:term:`PN`) is part of | ||
11191 | :term:`CVE_CHECK_PN_WHITELIST`, it is considered as patched. | ||
11192 | |||
11193 | - If the CVE ID is part of :term:`CVE_CHECK_WHITELIST`, it is | ||
11194 | considered as patched too. | ||
11195 | |||
11196 | - If the CVE ID is part of the patched CVE for the recipe, it is | ||
11197 | already considered as patched. | ||
11198 | |||
11199 | - Otherwise, the code checks whether the recipe version (:term:`PV`) | ||
11200 | is within the range of versions impacted by the CVE. If so, the CVE | ||
11201 | is considered as unpatched. | ||
11202 | |||
11134 | The CVE database is stored in :term:`DL_DIR` and can be inspected using | 11203 | The CVE database is stored in :term:`DL_DIR` and can be inspected using |
11135 | ``sqlite3`` command as follows:: | 11204 | ``sqlite3`` command as follows:: |
11136 | 11205 | ||