Andrew Geissler | 517393d | 2023-01-13 08:55:19 -0600 | [diff] [blame] | 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK |
| 2 | |
| 3 | Making Images More Secure |
| 4 | ************************* |
| 5 | |
| 6 | Security is of increasing concern for embedded devices. Consider the |
| 7 | issues and problems discussed in just this sampling of work found across |
| 8 | the Internet: |
| 9 | |
| 10 | - *"*\ `Security Risks of Embedded |
| 11 | Systems <https://www.schneier.com/blog/archives/2014/01/security_risks_9.html>`__\ *"* |
| 12 | by Bruce Schneier |
| 13 | |
| 14 | - *"*\ `Internet Census |
| 15 | 2012 <http://census2012.sourceforge.net/paper.html>`__\ *"* by Carna |
| 16 | Botnet |
| 17 | |
| 18 | - *"*\ `Security Issues for Embedded |
| 19 | Devices <https://elinux.org/images/6/6f/Security-issues.pdf>`__\ *"* |
| 20 | by Jake Edge |
| 21 | |
| 22 | When securing your image is of concern, there are steps, tools, and |
| 23 | variables that you can consider to help you reach the security goals you |
| 24 | need for your particular device. Not all situations are identical when |
| 25 | it comes to making an image secure. Consequently, this section provides |
| 26 | some guidance and suggestions for consideration when you want to make |
| 27 | your image more secure. |
| 28 | |
| 29 | .. note:: |
| 30 | |
| 31 | Because the security requirements and risks are different for every |
| 32 | type of device, this section cannot provide a complete reference on |
| 33 | securing your custom OS. It is strongly recommended that you also |
| 34 | consult other sources of information on embedded Linux system |
| 35 | hardening and on security. |
| 36 | |
| 37 | General Considerations |
| 38 | ====================== |
| 39 | |
| 40 | There are general considerations that help you create more secure images. |
| 41 | You should consider the following suggestions to make your device |
| 42 | more secure: |
| 43 | |
| 44 | - Scan additional code you are adding to the system (e.g. application |
| 45 | code) by using static analysis tools. Look for buffer overflows and |
| 46 | other potential security problems. |
| 47 | |
| 48 | - Pay particular attention to the security for any web-based |
| 49 | administration interface. |
| 50 | |
| 51 | Web interfaces typically need to perform administrative functions and |
| 52 | tend to need to run with elevated privileges. Thus, the consequences |
| 53 | resulting from the interface's security becoming compromised can be |
| 54 | serious. Look for common web vulnerabilities such as |
| 55 | cross-site-scripting (XSS), unvalidated inputs, and so forth. |
| 56 | |
| 57 | As with system passwords, the default credentials for accessing a |
| 58 | web-based interface should not be the same across all devices. This |
| 59 | is particularly true if the interface is enabled by default as it can |
| 60 | be assumed that many end-users will not change the credentials. |
| 61 | |
| 62 | - Ensure you can update the software on the device to mitigate |
| 63 | vulnerabilities discovered in the future. This consideration |
| 64 | especially applies when your device is network-enabled. |
| 65 | |
| 66 | - Regularly scan and apply fixes for CVE security issues affecting |
| 67 | all software components in the product, see ":ref:`dev-manual/vulnerabilities:checking for vulnerabilities`". |
| 68 | |
| 69 | - Regularly update your version of Poky and OE-Core from their upstream |
| 70 | developers, e.g. to apply updates and security fixes from stable |
| 71 | and LTS branches. |
| 72 | |
| 73 | - Ensure you remove or disable debugging functionality before producing |
| 74 | the final image. For information on how to do this, see the |
| 75 | ":ref:`dev-manual/securing-images:considerations specific to the openembedded build system`" |
| 76 | section. |
| 77 | |
| 78 | - Ensure you have no network services listening that are not needed. |
| 79 | |
| 80 | - Remove any software from the image that is not needed. |
| 81 | |
| 82 | - Enable hardware support for secure boot functionality when your |
| 83 | device supports this functionality. |
| 84 | |
| 85 | Security Flags |
| 86 | ============== |
| 87 | |
| 88 | The Yocto Project has security flags that you can enable that help make |
| 89 | your build output more secure. The security flags are in the |
| 90 | ``meta/conf/distro/include/security_flags.inc`` file in your |
| 91 | :term:`Source Directory` (e.g. ``poky``). |
| 92 | |
| 93 | .. note:: |
| 94 | |
| 95 | Depending on the recipe, certain security flags are enabled and |
| 96 | disabled by default. |
| 97 | |
| 98 | Use the following line in your ``local.conf`` file or in your custom |
| 99 | distribution configuration file to enable the security compiler and |
| 100 | linker flags for your build:: |
| 101 | |
| 102 | require conf/distro/include/security_flags.inc |
| 103 | |
| 104 | Considerations Specific to the OpenEmbedded Build System |
| 105 | ======================================================== |
| 106 | |
| 107 | You can take some steps that are specific to the OpenEmbedded build |
| 108 | system to make your images more secure: |
| 109 | |
| 110 | - Ensure "debug-tweaks" is not one of your selected |
| 111 | :term:`IMAGE_FEATURES`. |
| 112 | When creating a new project, the default is to provide you with an |
| 113 | initial ``local.conf`` file that enables this feature using the |
| 114 | :term:`EXTRA_IMAGE_FEATURES` |
| 115 | variable with the line:: |
| 116 | |
| 117 | EXTRA_IMAGE_FEATURES = "debug-tweaks" |
| 118 | |
| 119 | To disable that feature, simply comment out that line in your |
| 120 | ``local.conf`` file, or make sure :term:`IMAGE_FEATURES` does not contain |
| 121 | "debug-tweaks" before producing your final image. Among other things, |
| 122 | leaving this in place sets the root password as blank, which makes |
| 123 | logging in for debugging or inspection easy during development but |
| 124 | also means anyone can easily log in during production. |
| 125 | |
| 126 | - It is possible to set a root password for the image and also to set |
| 127 | passwords for any extra users you might add (e.g. administrative or |
| 128 | service type users). When you set up passwords for multiple images or |
| 129 | users, you should not duplicate passwords. |
| 130 | |
| 131 | To set up passwords, use the :ref:`ref-classes-extrausers` class, which |
| 132 | is the preferred method. For an example on how to set up both root and |
| 133 | user passwords, see the ":ref:`ref-classes-extrausers`" section. |
| 134 | |
| 135 | .. note:: |
| 136 | |
| 137 | When adding extra user accounts or setting a root password, be |
| 138 | cautious about setting the same password on every device. If you |
| 139 | do this, and the password you have set is exposed, then every |
| 140 | device is now potentially compromised. If you need this access but |
| 141 | want to ensure security, consider setting a different, random |
| 142 | password for each device. Typically, you do this as a separate |
| 143 | step after you deploy the image onto the device. |
| 144 | |
| 145 | - Consider enabling a Mandatory Access Control (MAC) framework such as |
| 146 | SMACK or SELinux and tuning it appropriately for your device's usage. |
| 147 | You can find more information in the |
| 148 | :yocto_git:`meta-selinux </meta-selinux/>` layer. |
| 149 | |
| 150 | Tools for Hardening Your Image |
| 151 | ============================== |
| 152 | |
| 153 | The Yocto Project provides tools for making your image more secure. You |
| 154 | can find these tools in the ``meta-security`` layer of the |
| 155 | :yocto_git:`Yocto Project Source Repositories <>`. |
| 156 | |