securing-images.rst 6.4 KB

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