jim.lai/OpenBMC
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Your Name
2026-04-23 17:07:55 +08:00
commit b7e39e063b
16725 changed files with 1625565 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
meta-security/docs/dm-verity-beaglebone.txt
+37
View File
@@ -0,0 +1,37 @@
dm-verity and beaglebone-black
------------------------------
Set/uncomment the MACHINE line for "beaglebone-yocto" if you haven't yet.
In addition to the basic dm-verity settings, you'll also want in local.conf:
IMAGE_BOOT_FILES:remove = "zImage"
IMAGE_BOOT_FILES:append = " zImage-initramfs-${MACHINE}.bin;zImage"
WKS_FILES = "${MACHINE}-verity.wks.in"
Read-only issues: The beaglebone BSP by default declares the following:
SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
...which are variables used by sysV init, in order to determine the
appropriate /etc/inittab entries. The problem that arises is that by
default, an on-target runtime check of /proc/consoles is used to finalize
the /etc/inittab -- and of course that fails a build with read-only-rootfs
[see the pkg_postinst_ontarget rule in the sysvinit rule for details.]
If you don't need a serial console, the quick fix is to add in local.conf
SERIAL_CONSOLES = ""
If you do need/want a serial console, then probably a local bbappend to
manually set the /etc/inittab as desired is easiest.
After running "wic create -e core-image-minimal beaglebone-yocto-verity"
you should have a "direct" image ready to write to a u-SD card. Remember
that the "direct" image contains the bootloader and partition table
already, so you'll be writing it to a device such as /dev/sdb and not
just a partition -- like /dev/sdb1
Also recall that booting from u-SD requires pressing and holding the S2
(SYSBOOT) button during power-on in order to divert the boot from the normal
soldered on storage and to the removable u-SD card.
meta-security/docs/dm-verity-systemd-hash-x86-64.txt
+43
View File
@@ -0,0 +1,43 @@
dm-verity and x86-64 and systemd - separate hash device
-------------------------------------------------------
Everything said in "dm-verity-systemd-x86-64.txt" applies here.
However booting under QEMU is not tested - only on real hardware.
So for your MACHINE you need to choose "genericx86-64".
Also, you'll need to point at the hash specific WKS file:
WKS_FILES += " systemd-bootdisk-dmverity-hash.wks.in"
The fundamental difference is to use a separate device/partition for
storage of the hash data -- instead of "hiding" it beyond the filesystem
in what is essentially a 5-10% oversized partition. This takes any manual
math calculations of size/offset out of the picture, and uses the kernel's
natural behaviour of compartmentalizing devices to ensure they are separate.
The example hash.wks file added here essentially adds a hash-only partition
directly after the filesystem partition. So the filesystem partition is
no longer "oversized" and no offsets are needed/used.
Since we are now using multiple partitions, we make a better effort to use
accepted GPT partition types and UUIDs based on the roothash. This means
easier sysadmin level use/debugging based on cfdisk output etc.
Generating the separate root hash image is driven off enabling this:
DM_VERITY_SEPARATE_HASH = "1"
Two other variables control the GPT UUIDs - set to x86-64 defaults:
DM_VERITY_ROOT_GUID ?= "4f68bce3-e8cd-4db1-96e7-fbcaf984b709"
DM_VERITY_RHASH_GUID ?= "2c7357ed-ebd2-46d9-aec1-23d437ec2bf5"
See: https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Finally, the UUIDs (not the "partition types" above) are based off of
the root node hash value as per the systemd "autodetect" proposed standard.
These will obviously change with every update/rebuild of the root image.
While not strictly coupled to any functionality at this point in time, it
does aid in easier debugging, and puts us in alignment with using systemd
inside the initramfs to replace manual veritysetup like configuration we
currently do in the initramfs today, should we decide to do so later on.
meta-security/docs/dm-verity-systemd-x86-64.txt
+77
View File
@@ -0,0 +1,77 @@
dm-verity and x86-64 and systemd
--------------------------------
In this example, we'll target combining qemux86-64 with dm-verity and
also systemd - systemd has dm-verity bindings and is more likely to be
used on x86.
While dm-verity in a qemu environment doesn't make practial sense as a
deployment - it can be a useful stepping stone for testing and getting to
a final physical deployment.
Set/uncomment the MACHINE line for "qemux86-64" if you haven't yet. It
should be the default if unspecified, but check to be sure. As of this
writing (kernel v6.1) the resulting qemux86-64 build can also be booted
successfully on physical hardware, but if you don't intend to use qemu,
you might instead want to choose "genericx86-64"
This will make use of wic/systemd-bootdisk-dmverity.wks.in -- note that it
contains a dependency on the meta-intel layer for microcode, so you'll need
to fetch and add that layer in addition to the meta-security related layers.
In addition to the basic dm-verity settings, choose systemd in local.conf:
DISTRO_FEATURES:append = " security systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
EFI_PROVIDER = "systemd-boot"
PACKAGECONFIG:append:pn-systemd = " cryptsetup"
Note the last line - you won't typically see that in on-line instructions
for enabling systemd. It is important for dm-verity, since it triggers
the build and installation of components like this onto the rootfs:
/lib/systemd/system-generators/systemd-veritysetup-generator
/lib/systemd/systemd-veritysetup
Now build the components for the wic image:
bitbake intel-microcode
bitbake core-image-minimal
Assemble the image:
------------------------------
build-qemu-x86_64$wic create systemd-bootdisk-dmverity -e core-image-minimal
INFO: Building wic-tools...
[...]
INFO: Creating image(s)...
INFO: The new image(s) can be found here:
./systemd-bootdisk-dmverity.wks-202304181413-sda.direct
The following build artifacts were used to create the image(s):
BOOTIMG_DIR: /home/paul/poky/build-qemu-x86_64/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
KERNEL_DIR: /home/paul/poky/build-qemu-x86_64/tmp/deploy/images/qemux86-64
NATIVE_SYSROOT: /home/paul/poky/build-qemu-x86_64/tmp/work/core2-64-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native
INFO: The image(s) were created using OE kickstart file:
/home/paul/poky/meta-security/wic/systemd-bootdisk-dmverity.wks.in
build-qemu-x86_64$
------------------------------
The "runqemu" script defaults were acceptable for testing with only the
verity image needing to be specified, i.e.
runqemu \
nographic \
qemux86-64 \
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-*.rootfs.ext4.verity
You will see the above "direct" image file and also similarly named
individual partition images. To boot on UEFI enabled physical hardware,
you need to simply write the "direct" image file to a USB stick with dd
and the partition images can largely be ignored.
Further information on interacting with the systemd UEFI loader is here:
https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/
meta-security/docs/dm-verity.txt
+123
View File
@@ -0,0 +1,123 @@
dm-verity and Yocto/OE
----------------------
The dm-verity feature provides a level of data integrity and resistance to
data tampering. It does this by creating a hash for each data block of
the underlying device as the base of a hash tree. There are many
documents out there to further explain the implementaion, such as the
in-kernel one itself:
https://docs.kernel.org/admin-guide/device-mapper/verity.html
The goal of this document is not to reproduce that content, but instead to
capture the Yocto/OE specifics of the dm-verity infrastructure used here.
Ideally this should enable a person to build and deploy an image on one of
the supported reference platforms, and then further adapt to their own
platform and specific storage requirements.
Basic Settings
--------------
Largely everything is driven off of a dm-verity image class; a typical
block of non MACHINE specific settings are shown below:
INITRAMFS_IMAGE = "dm-verity-image-initramfs"
DM_VERITY_IMAGE = "core-image-minimal"
DM_VERITY_IMAGE_TYPE = "ext4"
IMAGE_CLASSES += "dm-verity-img"
INITRAMFS_IMAGE_BUNDLE = "1"
Kernel Configuration
--------------------
Kernel configuration for dm-verity happens automatically via IMAGE_CLASSES
which will source features/device-mapper/dm-verity.scc when dm-verity-img
is used. [See commit d9feafe991c]
IMPORTANT: As per the top level README, you *must* put security in the
DISTRO_FEATURES, or else you won't get the dm-verity kernel settings.
Supported Platforms
-------------------
In theory, you can use dm-verity anywhere - there is nothing arch/BSP
specific in the core kernel support. However, at the BSP level, one
eventually has to decide what device(s) are to be hashed, and where the
hash tables are stored.
To that end, the BSP storage specifics live in meta-security/wic dir and
represent the current set of example configurations that have been tested
and submitted at some point.
Getting Started
---------------
This document assumes you are starting from the basic auto-created
conf/local.conf and conf/bblayers.conf from the oe-init-build-env
Firstly, you need the meta-security layer to conf/bblayers.conf along with
the dependencies it has -- see the top level meta-security README for that.
Note that if you are using dm-verity for your rootfs, then it enforces a
read-only mount right at the kernel level, so be prepared for issues such
as failed creation of temporary files and similar.
Yocto does support additional checks and changes via setting:
EXTRA_IMAGE_FEATURES = "read-only-rootfs"
...but since read-only is enforced at the kernel level already, using
this feature isn't a hard requirement. It may be best to delay/defer
making use of this until after you've established basic booting.
For more details, see the associated documentation:
https://docs.yoctoproject.org/dev/dev-manual/read-only-rootfs.html
Also add the basic block of dm-verity settings shown above, and select
your MACHINE from one of the supported platforms.
If there is a dm-verity-<MACHINE>.txt file for your BSP, check that for
any additional platform specific recommended settings, such as the
WKS_FILES which can specify board specific storage layout discussed below.
Then you should be able to do a "bitbake core-image-minimal" just like any
other normal build. What you will notice, is the content in
tmp/deploy/images/<MACHINE>/ now have suffixes like "rootfs.ext4.verity"
While you can manually work with these images just like any other build,
this is where the BSP specific recipes in meta-security/wic can simplify
things and remove a bunch of manual steps that might be error prone.
Consider for example, the beaglebone black WIC file, which contains:
part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat
--label boot --active --align 4 --fixed-size 32 --sourceparams="loader=u-boot" --use-uuid
part / --source rawcopy --ondisk mmcblk0 --sourceparams="file=${IMGDEPLOYDIR}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity"
bootloader --append="console=ttyS0,115200"
As can be seen, it maps out the partitions, including the bootloader, and
saves doing a whole bunch of manual partitioning and dd steps.
This file is copied into tmp/deploy/images/<MACHINE>/ with bitbake
variables expanded with their corresponding values for wic to make use of.
Continuing with the beaglebone example, we'll see output similar to:
----------------------
$ wic create -e core-image-minimal beaglebone-yocto-verity
[...]
INFO: Creating image(s)...
INFO: The new image(s) can be found here:
./beaglebone-yocto-verity.wks-202303070223-mmcblk0.direct
The following build artifacts were used to create the image(s):
BOOTIMG_DIR: /home/paul/poky/build-bbb-verity/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
KERNEL_DIR: /home/paul/poky/build-bbb-verity/tmp/deploy/images/beaglebone-yocto
NATIVE_SYSROOT: /home/paul/poky/build-bbb-verity/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/wic-tools/1.0-r0/recipe-sysroot-native
INFO: The image(s) were created using OE kickstart file:
/home/paul/poky/meta-security/wic/beaglebone-yocto-verity.wks.in
----------------------
The "direct" image contains the partition table, bootloader, and dm-verity
enabled ext4 image all in one -- ready to write to a raw device, such as a
u-SD card in the case of the beaglebone.
meta-security/docs/overview.txt
+197
View File
@@ -0,0 +1,197 @@
Meta-security Docs
=============
In this section the contents of the layer is listed, along with a short
help for each package.
== bastille ==
Bastille is a system hardening / lockdown program which enhances the
security of a Unix host. It configures daemons, system settings and
firewalls to be more secure. It can shut off unneeded services
like rcp and rlogin, and helps create "chroot jails" that help limit the
vulnerability of common Internet services like Web services and DNS.
usage : The functionality of Bastille which is available is
restricted to a purely informational one. The command:
bastille -c --os Yocto
will cause a series of menus containing security questions
about the system to be displayed to the user. For each
question, a default response, specified in the configuration
file which is installed with Bastille, will be selected.
The user may select an alternate response. When the user
has completed the sequence of menus Bastille saves the
responses to the configuration file.
The command:
bastille -l lists the configuration files that Bastille
is able to locate.
The other functionality which Bastille is intended to provide
is actually unavailable. This is not due to errors in poky
installation or configuration of the application. The Bastille
distribution is no longer supported. Significant modifications
would be required to make it possible to make use of the
functionality which is currently unavailable.
Additional information about Bastille can be found in the package
README file and other documentation.
Alternatives to Bastille include buck-security and checksecurity,
described elsewhere in this file.
== redhat-security ==
Sometimes you want to check different aspects of a distribution for security problems.
This can be anything from file permissions to correctness of code. This is a collection of those tools.
Depending on what information the tool has to access, it may need to be run as root.
- rpm-chksec.sh : This will take an rpm name as input and verify each ELF file to see if its compiled with the intended flags
to most effectively use PIE and RELRO. Green is good, Orange could use work but is acceptable, and Red needs fixing.
It has a mode --all that is the equivalent of using rpm -qa and feeding the packages to it.
In this mode it will only give a summary result for the package. To find which files don't comply,
re-run using just the package name.
!!! WARNING !!! - in order to use this script you need to add to your conf/local.conf file the following lines:
IMAGE_ROOTFS_EXTRA_SPACE = "" - specifying the extra space of the image
IMAGE_FEATURES += "package management" - for the correct output of rpm -qa
- find-nodrop-groups.sh : This will scan a whole file system to see if a program makes calls to change UID
and GID without also calling setgroups or initgroups.
- rpm-drop-groups.sh : Same as above, but takes an rpm name instead.
- find-chroot.sh : This script scans the whole file system looking for ELF files that calls chroot(2) that also do not include a call to chdir.
Programs that fail to do this do not have the cwd inside the chroot. This means the app can escape the protection that was intended.
- find-chroot-py.sh : This test is like the one above except it examines python scripts for the same problem.
- find-execstack.sh : This program scans the whole file system for ELF programs that have marked the stack as being executable.
This means that if the program has another vulnerablity such as stack buffer overflow,
any code the attacker places there is executable. Any program found must be fixed.
- find-hidden-exec.sh : This program scans the whole file system looking for excutables that are hidden.
Anything found must be investigated since its highly unusual for executables to be hidden.
- find-sh4errors.sh : This program scans the whole file system looking for shell scripts.
It then does a sh -n on the script which causes bash to parse the file to see if there are any mistakes.
- selinux-check-devices.sh : This script checks the /dev directory to see if there are any devices that are not correctly labeled.
Anything found by this test should be reported so that selinux policy can be fixed.
This test is very hardware specific, so to be effective a lot of people with different hardware
should run this test each upstream kernel version release.
- selinux-ls-unconfined.sh : This script scans the running processes and looks for anything labeled with initrc_t or inetd.
These both mean that there are daemons that do not have policy and are therefore running unconfined.
These should be reported as SE Linux policy problems. Because it checks currently running daemons,
the more you have running, the better the test is.
- find-sh4tmp.sh : This script scans the whole filesystem to check if shell scripts are using well known tmp file names
instead of obscure ones created by something like mktemp.
- find-elf4tmp.sh : This script scans the whole file system for ELF files using /tmp. When it finds this,
it also looks to see if any of the known good random name generator functions is called by looking
at the symbol table. If not, it will output the string.
- lib-bin-check.sh : This will check all installed library packages to see if an application is also part of the package.
The relationship to security is that the SHA256 hash check will fail if a 32 bit version overwrites it.
Also, the less binaries on a system, the more secure it is by virtue of removing the chance for an exploitable bug.
usage : simply invoke the script name in the terminal.
== pax-utils ==
( This package can be found in oe-core )
pax-utils is a small set of various PaX aware and related utilities for
ELF binaries.
- scanelf : With this application you can print out information specific to the ELF structure of a binary.
For more help please consult the man pages or the readme file.
- pspax : is a user-space utility that scans the proc directory and list
ELF types, as well as their respective PaX flags and filenames and
attributes. Depending on build options, it may additionaly display the
process running set of capabilities.
- scanmacho : is a user-space utility to quickly scan given
Mach-Os, directories, or common system paths for different information. This
may include Mach-O types, their install_names, etc.
- dumpelf : is a user-space utility to dump all of the internal
ELF structures into the equivalent C structures for fun debugging and/or
reference purposes.
usage : simply invoke the script name in the terminal.
== buck-security ==
Buck-Security is a security scanner for Debian and Ubuntu Linux. It runs a couple of important checks and helps you to harden your Linux
system. This enables you to quickly overview the security status of your Linux system.
usage : !!! before starting to use this tool please run the following command: !!!
export GPG_TTY=`tty`
This command is needed for the usage of the comand --make-checksum, which creates
a checksum for the files in the system.
switch to directory /usr/local/buck-security.
before running the script, you should check the activated checks in conf/buck-security.conf file.
after altering the changes, save the file and simply run :
./buck-security
you can choose between different outputs : 1, 2(default) or 3.
More detailed usage can be found typing ./buck-security --help
== libseccomp ==
The libseccomp library provides and easy to use, platform independent, interface to the Linux Kernel's syscall filtering mechanism: seccomp.
The libseccomp API is designed to abstract away the underlying BPF based syscall filter language and present a more conventional
function-call based filtering interface that should be familiar to, and easily adopted by application developers.
usage : More detailed usage can be found in the man pages and README file of the package.
== checksecurity ==
checksecurity is a simple package which will scan your system for several simple security holes.
It uses a simple collection of plugins, all of which are shell scripts which are configured by environmental variables.
usage : To start checksecurity simply write in the terminal :
checksecurity
More detailed usage can be found in the man pages and README file of the package.
== nikto ==
Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items,
including over 6500 potentially dangerous files/CGIs, checks for outdated versions of over 1250 servers, and version specific
problems on over 270 servers. It also checks for server configuration items such as the presence of multiple index files,
HTTP server options, and will attempt to identify installed web servers and software.
usage : To start nikto simply write in the terminal :
nikto
More detailed usage can be found in the man pages and README file of the package.
License
=======
All metadata is MIT licensed unless otherwise stated. Source code included
in tree for individual recipes is under the LICENSE stated in each recipe
(.bb file) unless otherwise stated.