From: "Quentin Schulz" <quentin.schulz@theobroma-systems.com>
To: Michael Opdenacker <michael.opdenacker@bootlin.com>
Cc: docs@lists.yoctoproject.org
Subject: Re: [docs] [PATCH] manuals: initial documentation for CVE management
Date: Mon, 2 Aug 2021 11:36:18 +0200 [thread overview]
Message-ID: <20210802093618.npbsjvxyh7x3pbtl@fedora> (raw)
In-Reply-To: <20210730185433.188851-1-michael.opdenacker@bootlin.com>
Hi Michael,
On Fri, Jul 30, 2021 at 08:54:33PM +0200, Michael Opdenacker wrote:
> This starts to document vulnerability management
> and the use of the CVE_PRODUCT variable
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
> ---
> documentation/dev-manual/common-tasks.rst | 46 +++++++++++++++++++++++
> documentation/ref-manual/variables.rst | 11 ++++++
> 2 files changed, 57 insertions(+)
>
> diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
> index 9a6f4e1a8e..aa296850f8 100644
> --- a/documentation/dev-manual/common-tasks.rst
> +++ b/documentation/dev-manual/common-tasks.rst
> @@ -10528,6 +10528,9 @@ follows:
> 1. *Identify the bug or CVE to be fixed:* This information should be
> collected so that it can be included in your submission.
>
> + See :ref:`dev-manual/common-tasks:checking for vulnerabilities`
> + for details about CVE tracking.
> +
> 2. *Check if the fix is already present in the master branch:* This will
> result in the most straightforward path into the stable branch for the
> fix.
> @@ -11090,6 +11093,49 @@ the license from the fetched source::
>
> NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
>
> +Checking for Vulnerabilities
> +============================
> +
> +Vulnerabilities in images
> +-------------------------
> +
> +The Yocto Project has an infrastructure to track and address unfixed
> +known security vulnerabilities, as tracked by the public
> +`Common Vulnerabilities and Exposures (CVE) <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Common-5FVulnerabilities-5Fand-5FExposures&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=hekyLAdEcYu52ifxV5ERIziCTL0mv8hKI_2zFGHfCiY&s=6SHbCNpyGeEIS-wx0ocS3IvlInldBWzG0CPei2x4xWI&e= >`__
> +database.
> +
> +To know which packages are vulnerable to known security vulnerabilities,
> +add the following setting to your configuration::
> +
> + INHERIT += "cve-check"
> +
> +This way, at build time, BitBake will warn you about known CVEs
> +as in the example below::
> +
> + WARNING: flex-2.6.4-r0 do_cve_check: Found unpatched CVE (CVE-2019-6293), for more information check /poky/build/tmp/work/core2-64-poky-linux/flex/2.6.4-r0/temp/cve.log
> + WARNING: libarchive-3.5.1-r0 do_cve_check: Found unpatched CVE (CVE-2021-36976), for more information check /poky/build/tmp/work/core2-64-poky-linux/libarchive/3.5.1-r0/temp/cve.log
> +
> +It is also possible to check the CVE status of individual packages as follows::
> +
> + bitbake -c cve_check flex libarchive
> +
> +Note that OpenEmbedded-Core keeps a list of known unfixed CVE issues which can
> +be ignore. You can pass this list to the check as follows::
> +
s/ignore/ignored/
> + bitbake -c cve_check libarchive -R conf/distro/include/cve-extra-exclusions.inc
> +
> +Enabling vulnerabily tracking in recipes
> +----------------------------------------
> +
> +The :term:`CVE_PRODUCT` variable defines the name used to match the recipe name
> +against the name in the upstream `NIST CVE database <https://urldefense.proofpoint.com/v2/url?u=https-3A__nvd.nist.gov_&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=hekyLAdEcYu52ifxV5ERIziCTL0mv8hKI_2zFGHfCiY&s=2VyieDwk2kXSn66jsySlUL_eB6CvuUWR-yRh-DMaIv0&e= >`__.
> +
> +The CVE database is created by a recipe and stored in :term:`DL_DIR`.
A bit unclear to me the "created by a recipe" part. I'm not sure it is
important information?
> +For example, you can look inside the database using the ``sqlite3`` command
> +as follows::
> +
> + sqlite3 downloads/CVE_CHECK/nvdcve_1.1.db .dump | grep CVE-2021-37462
> +
What about:
The CVE database is stored in :term:`DL_DIR` and can be inspected using
``sqlite3`` command as follows:
[...]
?
If the "created by a recipe" part is important maybe it needs to be a
bit more explicit what it means?
> Using the Error Reporting Tool
> ==============================
>
> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
> index b61de1993d..72e1c832c6 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -1471,6 +1471,17 @@ system and gives an overview of their function and contents.
> variable only in certain contexts (e.g. when building for kernel
> and kernel module recipes).
>
> + :term:`CVE_PRODUCT`
> + In a recipe, defines the name used to match the recipe name
> + against the name in the upstream `NIST CVE database <https://urldefense.proofpoint.com/v2/url?u=https-3A__nvd.nist.gov_&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=hekyLAdEcYu52ifxV5ERIziCTL0mv8hKI_2zFGHfCiY&s=2VyieDwk2kXSn66jsySlUL_eB6CvuUWR-yRh-DMaIv0&e= >`__.
> +
> + This is only needed in case of a mitmatch, or if the
s/mitmatch/mismatch/
Technically, it is needed by all recipes, it's just that the default is
${BPN}.
I'd rather say that "
The default is ${:term:`BPN`}. If it does not match the name in NIST CVE
database or matches with multiple entries in the database, the default
value needs to be changed.
"
What do you think?
> + recipes matches with multiples entries in the database.
> +
s/recipes/recipe name/
> + Here is an example from the Berkeley DB recipe (``db_${PV}.bb``)::
> +
``db_${PV}.bb`` is an invalid name for a recipe name I think, can we
just give it the current version (and eventually says from which release
it is?). Or maybe we can just not give the full recipe name but just
that it's named db and link to its page on the layer index:
https://layers.openembedded.org/layerindex/recipe/544/ so that it's
always up-to-date?
Thanks,
Quentin
next prev parent reply other threads:[~2021-08-02 9:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 18:54 [PATCH] manuals: initial documentation for CVE management Michael Opdenacker
2021-08-02 9:36 ` Quentin Schulz [this message]
2021-08-02 14:49 ` [docs] " Michael Opdenacker
2021-08-02 14:59 ` Richard Purdie
[not found] <1696A6679AD2D10A.1941@lists.yoctoproject.org>
2021-07-30 18:59 ` Michael Opdenacker
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=20210802093618.npbsjvxyh7x3pbtl@fedora \
--to=quentin.schulz@theobroma-systems.com \
--cc=docs@lists.yoctoproject.org \
--cc=michael.opdenacker@bootlin.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.