Linux Extended Verification Module (EVM) is a security feature in the Linux kernel designed to enhance the integrity of the system by protecting extended attributes (xattrs) of files. These attributes often include security-related metadata, such as those used by the Integrity Measurement Architecture (IMA), Linux Security Modules (LSMs) like SELinux or Smack, and other extended attributes.
bugwhine
A tech blog, vaguely centered around Fedora Linux.
Friday, May 17, 2024
Integrity Measurement Architecture (IMA) on Raspian
Sunday, December 3, 2023
dm-integrity, dm-crypt, luks
Build dm-integrity for RPI
dm-integrity (no encryption)
Create an image file as backing for a loop device
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 2.28869 s, 45.8 MB/s
Create the loop device
Create key, format, open using integrity setup
dm-crypt (no integrity)
Create key and format, open using cryptsetup
dm-integrity + dm-crypt
Create key and format, open using cryptsetup
Monday, April 10, 2023
Yocto - building a dmverity/squashfs ro-rootfs
Configure the kernel with dm-verity support
$ mv tmp/work/qemux86_64-poky-linux/linux-yocto/*/fragment.cfg ../meta-mylayer/recipes-kernel/linux/linux-yocto/dmverity.cfg
No DES (i.e. don't encrypt the private key with Data Encryption Standard)
Specifies the number of days to make a certificate valid for.
Specifies the serial number to use.
In a certificate, the serial number is chosen by the CA which issued the certificate. It is just written in the certificate. The CA can choose the serial number in any way as it sees fit, not necessarily randomly (and it has to fit in 20 bytes). A CA is supposed to choose unique serial numbers, that is, unique for the CA.
https://en.wikipedia.org/wiki/X.509#Sample_X.509_certificates
Sunday, April 9, 2023
Yocto - read-only rootfs (squashfs) + ext4 overlay (qemu)
Experimenting with a qemu yocto build that models an Embedded system with a read-only rootfs, and writeable overlay.
Basic yocto setup
Clone git://git.yoctoproject.org/poky
Checkout dunfell branch
Clone https://github.com/marcusfolkesson/meta-readonly-rootfs-overlay.git
Update the compatibility in meta-readonly-rootfs-overlay/conf/layer.conf to match your poky branch
source oe-init-build-env
Add meta-readonly-rootfs-overlay to build/conf/bblayers.conf
Create own layer meta-mylayer (git@github.com:bugwhine/meta-mylayer.git)
and add to build/conf/bblayers.conf
Setup meta-mylayer/conf/layer.conf containing the boilerplate -
Add squashfs support to the yocto kernel
$ bitbake linux-yocto -c kernel_configme -fUse menuconfig to add squashfs support, and customize options as desired
$ mkdir -p meta-mylayer/recipes-kernel/linux
$ mv fragment.cfg ../meta-mylayer/recipes-kernel/linux/linux-yocto/squashfs.cfg
Setup an image (wic)
Build and run
...
Confirm that the overlay is working
Wednesday, April 1, 2020
TP-Link TL WN823N on Raspberry Pi 2B
https://elinux.org/RPi_USB_Wi-Fi_Adapters
states -
TL-WN823N Works out of box on Raspian using powered USB Hub
For me, although it was identified on USB, wlan0 did not exist.
The procedure from -
https://www.raspberrypi.org/forums/viewtopic.php?p=462982#p462982
resolved it, such that
pi@raspberrypi:~ $ dmesg |grep -E "8192eu|wlan"
[ 6.130806] 8192eu: loading out-of-tree module taints kernel.
[ 6.282145] RTL871X: rtl8192eu v4.4.1_17696.20160509_BTCOEX20160412-0042
[ 6.282164] RTL871X: rtl8192eu BT-Coex version = BTCOEX20160412-0042
[ 6.417300] RTL871X: rtw_ndev_init(wlan0) if1 mac_addr=50:3e:aa:86:9d:85
[ 6.419838] usbcore: registered new interface driver rtl8192eu
[ 11.433648] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 20.945234] RTL871X: rtw_set_802_11_connect(wlan0) fw_state=0x00000008
[ 22.527221] RTL871X: rtw_cfg80211_indicate_connect(wlan0) BSS not found !!
[ 23.053309] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Bus 001 Device 004: ID 2357:0109 TP-Link TL WN823N RTL8192EU
Sunday, September 8, 2019
Docker Toolbox (on Windows) cheatsheet
$ docker run -t -i ubuntu /bin/bash
$ exit
Commit it to a new image
$ docker commit d1dbe5528e65 commitrunning
Open VirtualBox, to configure shared drives
Setup a shared folder named 'd' with path 'd:\"
In the (Linux) shell (docker@default) give the commands
docker@default:~$ sudo mkdir /d
docker@default:~$ sudo mount -t vboxsf d /d
Add the volume to the image
$ docker run -ti -v //d/repo/:/repo commitrunning /bin/bash
Display containers
$ docker ps -a
Display images
$ docker image ls
Display dockerfile for container
$ docker container inspect unruffled_shtern
About dockerfiles, containers, images
https://blog.octo.com/en/docker-registry-first-steps/
Connect to running container
$ docker exec -it unruffled_shtern /bin/bash
Friday, May 4, 2018
Yocto kernel in-tree development work-flows
Traditional Kernel Development
Preparation
- create a layer for holding kernel patches, and configuration fragments
- create an append recipe (eg. meta-mylayer/recipes-kernel/linux/linux-yocto_4.12.bbappend) that identifies the patches and configuration fragments that you wish to apply
- create a local clone of the Yocto Linux Kernel
Development Loop
- create a layer for holding kernel patches
- create an append recipe (eg. meta-mylayer/recipes-kernel/linux/linux-yocto_4.12.bbappend) that identifies the patches that you wish to apply
- (build and install an extensible SDK)
- build a clean image
- checkout the kernel source using 'devtool modify linux-yocto'. This step creates a local copy of the kernel source, in the (SDK) workspace, as well a recipe to include it in the build
Preparation
- create an append recipe (eg. meta-mylayer/recipes-kernel/linux/linux-yocto_4.12.bbappend) that identifies the patches and configuration fragments that you wish to apply
- in the .bbappend recipe add the following -
inherit externalsrc
EXTERNALSRC = "/repo/linux-custom"
SRCTREECOVEREDTASKS := "do_validate_branches do_kernel_checkout do_fetch"