lnr is a script in oe-core that creates relative symlinks, with the same
behaviour as `ln --relative --symlink`. It was added back in 2014[1] as
not all of the supported host distributions at the time shipped
coreutils 8.16, the first release with --relative.
However the oldest coreutils release in the supported distributions is
now 8.22 in CentOS 7, so lnr can be deprecated and users switched to ln.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Update the layers to use the kirkstone namespace. No compatibility is made
for honister due to the variable renaming.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Assign a weak default value for MODSIGN_KEY_DIR so the other layers can
set a default value for them as well.
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Introduce IMA_FORCE to allow the IMA policy be applied forcely even
'no_ima' boot parameter is available.
This ensures the end users have a way to disable 'no_ima' support if
they want to, because it may expose a security risk if an attacker can
find a way to change kernel arguments, it will easily bypass rootfs
authenticity checks.
Signed-off-by: Sergio Prado <sergio.prado@toradex.com>
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
IMA_POLICY is being referred as policy recipe name in some places and it
is also being referred as policy file in other places, they are
conflicting with each other which make it impossible to set a IMA_POLICY
global variable in config file.
Fix it by dropping IMA_POLICY definitions from policy recipes
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
This ensures when a end user change the IMA_EVM_X509 key file,
ima-evm-keys recipe will be rebuilt.
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The current logic in ima-evm-rootfs.bbclass does not guarantee
ima_evm_sign_rootfs is the last function in IMAGE_PREPROCESS_COMMAND
by appending to it, for instance, if there are other "_append" being
used as it's the case in openembedded-core/meta/classes/image.bbclass:
| IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;' \
| if bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) \
| and not bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True,
| False, d) else ''} reproducible_final_image_task; "
and ima-evm-rootfs should be in IMAGE_CLASSES instead of in INHERIT
since that would impact all recipes but not only image recipes.
To fix the above issues, we introduce a ima_evm_sign_handler setting
IMA/EVM rootfs signing requirements/dependencies in event
bb.event.RecipePreFinalise, it checks 'ima' distro feature to decide if
IMA/EVM rootfs signing logic should be applied or not.
Also add ima-evm-keys to IMAGE_INSTALL.
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
'ima' does not have to be in native DISTRO_FEATURES, unset it to avoid
sanity check for ima-evm-utils-native.
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Updating BBFILES with := isn't the standard way and can break
parsing under certain conditions, instead use += which is widely used.
Signed-off-by: Sajjad Ahmed <sajjad_ahmed@mentor.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
As pointer by Martin Jansa, keyutils package is now a part of meta-oe,
so switch to using keyutils from that layer.
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Add bbclass responsible for handling signing of kernel modules.
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
fixup class to avoid including in every configure task
Signed-off-by: Armin Kuster <akuster808@gmail.com>
data/debug-keys will be reused for demo modsign keys, so rename
IMA_EVM_BASE to more generic INTEGRITY_BASE.
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
