Overview:
During testing on IPFire Core Update 189, it was discovered that the Landlock Linux Security Module (LSM) is not properly initialised, leading to Suricata’s Landlock-based protections being inactive. Despite Landlock being enabled in the kernel and configured in Suricata’s YAML file, no active LSMs are detected, and `securityfs` is not automatically mounted. Further investigation reveals that Landlock remains uninitialised even after manually mounting `securityfs`.

This issue may relate to a similar problem reported earlier (Bug #13645), where Landlock was not properly loaded in previous IPFire versions. While a patch was issued in Core Update 186 to address this issue, it seems the problem persists or has regressed in the current CU189 build.

Steps to Reproduce:

1. Install IPFire Core Update 189 (Development Build) on a system. This may also occur on previous releases.

2. Check the status of active LSMs:

     grep ^LSM: /proc/self/status

   Expected output: `LSM: landlock, lockdown, yama, ...`
   Actual output: No output.

3. Verify if `securityfs` is mounted:

     mount | grep securityfs

   Expected output: `securityfs on /sys/kernel/security ...`
   Actual output: No output (indicating `securityfs` is not mounted).

4. Manually mount `securityfs`:

     mount -t securityfs securityfs /sys/kernel/security

   After mounting, verify again if Landlock is present:

     ls /sys/kernel/security/landlock

   Actual output: No such file or directory.

5. Inspect `/etc/suricata/suricata.yaml` for Landlock configuration:

     grep -A5 'landlock:' /etc/suricata/suricata.yaml

   Result:

     landlock:
       enabled: yes

   Although Landlock is enabled in the configuration file, it is not effective without proper kernel support.

Additional Investigation:

- No `/sys/kernel/security/lockdown` file exists, which may indicate that the kernel's security features, including Landlock, are not fully enabled.
- Running `cat /proc/cmdline | grep lsm` returns no output, meaning the `lsm=` parameter is not passed during boot, which could prevent the LSM from loading correctly.
- The `/sys/kernel/security/lsm` file is also missing, further indicating that Landlock and other security modules are not active.
- Kernel logs (`dmesg`) show no entries related to Landlock, meaning the kernel isn't even attempting to initialise it.
- The kernel configuration includes `CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,bpf"`, but this configuration is ineffective without proper initialisation.

---

Additional Information:
This issue was identified during Suricata 7 testing, as noted by @MS on 8 April 2024:

- Even when Landlock was enabled with incorrect data, Suricata continued running, indicating Landlock might not have been properly initialised.
- The `/sys/kernel/security/lockdown` file returned `[none] integrity confidentiality`, suggesting that Landlock enforcement was not functioning.
- A patch (Fixes: #13645) was introduced to properly load the Landlock module and modify the kernel configuration to include `CONFIG_LSM="landlock, lockdown, yama, loadpin, safesetid, integrity, bpf"`.
- Another patch reverted a change that had disabled Landlock in Suricata’s YAML configuration.

Despite these fixes, the Landlock module still appears to not be properly initialised in CU189, and `securityfs` is not mounted by default, causing Suricata’s file system restrictions to remain inactive.