diff --git a/documentation/security-manual/read-only-rootfs.rst b/documentation/security-manual/read-only-rootfs.rst index 251178ed5458..55eb853dc239 100644 --- a/documentation/security-manual/read-only-rootfs.rst +++ b/documentation/security-manual/read-only-rootfs.rst @@ -23,13 +23,17 @@ Creating the Root Filesystem To create the read-only root filesystem, simply add the "read-only-rootfs" feature to your image, normally in one of two ways. The first way is to add the "read-only-rootfs" image feature in the -image's recipe file via the :term:`IMAGE_FEATURES` variable:: +image's recipe file via the :term:`IMAGE_FEATURES` variable: + +.. code-block:: bitbake IMAGE_FEATURES += "read-only-rootfs" As an alternative, you can add the same feature from within your :term:`Build Directory`'s ``local.conf`` file with the -associated :term:`EXTRA_IMAGE_FEATURES` variable, as in:: +associated :term:`EXTRA_IMAGE_FEATURES` variable, as in: + +.. code-block:: bitbake EXTRA_IMAGE_FEATURES = "read-only-rootfs" diff --git a/documentation/security-manual/securing-images.rst b/documentation/security-manual/securing-images.rst index 13ab63ddd8be..3c01c1f643bd 100644 --- a/documentation/security-manual/securing-images.rst +++ b/documentation/security-manual/securing-images.rst @@ -82,7 +82,9 @@ your build output more secure. The security flags are in the Use the following line in your ``local.conf`` file or in your custom distribution configuration file to enable the security compiler and -linker flags for your build:: +linker flags for your build: + +.. code-block:: bitbake require conf/distro/include/security_flags.inc @@ -96,7 +98,9 @@ system to make your images more secure: and allow the use of empty passwords or root logins. This is typically done by adding the values "allow-empty-password", "allow-root-login", and "empty-root-password" to your build's image features, commonly with the - addition of the line:: + addition of the line: + + .. code-block:: bitbake EXTRA_IMAGE_FEATURES = "allow-empty-password empty-root-password allow-root-login" diff --git a/documentation/security-manual/sstate-signing.rst b/documentation/security-manual/sstate-signing.rst index 74a5d6bf07da..565f51e843ab 100644 --- a/documentation/security-manual/sstate-signing.rst +++ b/documentation/security-manual/sstate-signing.rst @@ -86,7 +86,9 @@ they are generated. The generation of new artifacts is done once a task has finished being executed. For the following sections let's assume that the build system has the shared -state directory location (:term:`SSTATE_DIR`) defined as follows:: +state directory location (:term:`SSTATE_DIR`) defined as follows: + +.. code-block:: bitbake SSTATE_DIR = "${TOPDIR}/sstate-cache" @@ -120,7 +122,9 @@ Enabling Shared State Signing ----------------------------- Create a new :term:`configuration file` on your host **in a safe location** and -add the two following statements:: +add the two following statements: + +.. code-block:: bitbake SSTATE_VERIFY_SIG = "1" SSTATE_SIG_KEY = "4049A47E3AAA99D0250966DC5B97632FA7F4E942" @@ -196,7 +200,9 @@ you can verify them with the public key counterpart of the private key. shared between multiple hosts. From a :term:`configuration file` such as the :ref:`site configuration file -`, include the following statements:: +`, include the following statements: + +.. code-block:: bitbake SSTATE_VERIFY_SIG = "1" SSTATE_VALID_SIGS = "5B97632FA7F4E942" @@ -255,7 +261,9 @@ Let's verify that signature verification works: .. note:: To make sure shared state verification is working, you can set a "fake" - public key identifier in :term:`SSTATE_VALID_SIGS`:: + public key identifier in :term:`SSTATE_VALID_SIGS`: + + .. code-block:: bitbake SSTATE_VALID_SIGS = "CAFECAFECAFECAFE" diff --git a/documentation/security-manual/vulnerabilities.rst b/documentation/security-manual/vulnerabilities.rst index 38fbd2c7e358..e3fc6fe768b8 100644 --- a/documentation/security-manual/vulnerabilities.rst +++ b/documentation/security-manual/vulnerabilities.rst @@ -35,7 +35,9 @@ Directory`: $ bitbake-config-build enable-fragment core/yocto/sbom-cve-check -Or add the following statement to a :term:`configuration file`:: +Or add the following statement to a :term:`configuration file`: + +.. code-block:: bitbake OE_FRAGMENTS += "core/yocto/sbom-cve-check" @@ -44,7 +46,9 @@ recommended settings to use it. The CVE database contains some old incomplete entries which have been deemed not to impact :term:`OpenEmbedded-Core (OE-Core)`. These CVE entries can be excluded -from the check by adding the following statement:: +from the check by adding the following statement: + +.. code-block:: bitbake include conf/distro/include/cve-extra-exclusions.inc @@ -165,7 +169,9 @@ in the recipe name to CVE product mapping. These mapping issues can be fixed by the :term:`CVE_PRODUCT` variable inside the recipe. This defines the name of the software component in the upstream `NIST CVE database `__. -The variable supports using vendor and product names like this:: +The variable supports using vendor and product names like this: + +.. code-block:: bitbake CVE_PRODUCT = "flex_project:flex westes:flex" @@ -200,7 +206,9 @@ version does or likely might introduce incompatibilities, extracting and backporting patches is preferred. Here is an example of fixing CVE security issues with patch files, -an example from the :oe_layerindex:`ffmpeg recipe for dunfell `:: +an example from the :oe_layerindex:`ffmpeg recipe for dunfell `: + +.. code-block:: bitbake SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \ file://mips64_cpu_detection.patch \ @@ -283,7 +291,9 @@ status to ``Patched`` in the generated reports. If analysis shows that the CVE issue does not impact the recipe due to configuration, platform, version or other reasons, the CVE can be marked as ``Ignored`` by using the :term:`CVE_STATUS` variable flag with appropriate reason which is mapped to ``Ignored``. -The entry should have the format like:: +The entry should have the format like: + +.. code-block:: bitbake CVE_STATUS[CVE-2016-10642] = "cpe-incorrect: This is specific to the npm package that installs cmake, so isn't relevant to OpenEmbedded" @@ -364,7 +374,9 @@ Example: $ cd openembedded-core/meta/recipes-kernel/linux/ $ ./generate-cve-exclusions.py ~/cvelistV5 6.12.27 > ~/meta-custom/recipes-kernel/linux/cve-exclusion_6.12.inc -Don't forget to update your kernel recipe with:: +Don't forget to update your kernel recipe with: + +.. code-block:: bitbake include cve-exclusion_6.12.inc @@ -396,7 +408,9 @@ build a binary. Therefore, it needs to be configured in the kernel to extract the kernel compiled files. If you are using the ``linux-yocto`` recipe, enable it by adding the following -in a :term:`configuration file` or in a ``.bbappend``:: +in a :term:`configuration file` or in a ``.bbappend``: + +.. code-block:: bitbake KERNEL_EXTRA_FEATURES:append = " features/debug/debug-kernel.scc" @@ -413,7 +427,9 @@ The sources for the kernel are stored under ``tmp/pkgdata//debugsources/linux-yocto-debugsources.json.zstd``. In order to include the information into the :term:`SPDX` file to filter out source files that are not used to compile the kernel, add the following in a -:term:`configuration file`:: +:term:`configuration file`: + +.. code-block:: bitbake SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"