Miscellaneous

This section covers additional hardening measures applicable to the Open World environment. Because Bunker OS is a minimal, audited image with a very small attack surface, many of these controls are most relevant for the more general-purpose Open World environment where customer workloads run. All measures described here are pre-applied in the BCA reference design.

Password Policy Enforcement

During development it is common to leave password enforcement disabled. Before shipping to production, strong password enforcement must be enabled in Open World. BCA uses pam_pwquality (the successor to pam_cracklib) to enforce password quality. Enable it by adding the module to /etc/pam.d/common-password:

password    requisite    pam_pwquality.so retry=3

Configure the policy in /etc/security/pwquality.conf:

minlen = 12
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1

A password aging policy can be configured in /etc/login.defs:

PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   7

For service-to-service authentication, prefer key-based SSH authentication over passwords entirely. SSH host keys to access Open World should use Ed25519 and be provisioned at image build time.

Kernel Hardening Flags

The Bunker OS kernel is built with a set of compile-time hardening options that are enabled by default in the BCA kernel recipe. The same configuration can applied to the Open World kernel recipe:

Address Space Layout Randomisation (ASLR)

CONFIG_RANDOMIZE_BASE=y randomises the kernel base address at each boot, making it significantly harder for attackers to predict target addresses for code-reuse attacks.

Stack Protector

CONFIG_STACKPROTECTOR_STRONG=y inserts canary values at stack frame boundaries. Any stack overflow that overwrites a return address will be detected before the function returns, triggering a kernel panic.

Control Flow Integrity (CFI)

On ARM64 (v8.3+), CONFIG_CFI_CLANG=y (when building with Clang) enforces forward-edge CFI by validating that indirect calls only target functions with compatible type signatures.

Hardened usercopy

CONFIG_HARDENED_USERCOPY=y validates the source and destination of all kernel-to-user and user-to-kernel memory copies, detecting out-of-bounds accesses that would otherwise be silent.

Read-Only Data and Code Sections

CONFIG_STRICT_KERNEL_RWX=y and CONFIG_STRICT_MODULE_RWX=y enforce that kernel text and read-only data pages are never writable and that data pages are never executable.

Network Isolation

Network isolation is a core security property of BCA. Bunker OS has no direct network connectivity and is isolated from external threats. The CLARE Hypervisor grants network access exclusively to Open World through physical network interface passthrough in the reference design.

All inter-domain communication between Open World and Bunker OS occurs through the secure vsock channel using Turmux RPC, not network protocols. This separation ensures that even if Open World is compromised, an attacker cannot directly access network services or protocols on Bunker OS, they can only invoke RPC methods that Bunker OS explicitly exposes.

For custom deployments where virtualized networking is preferred, virtio-net can be configured to expose virtual interfaces to Open World instead of physical passthrough.

AppArmor and Seccomp

AppArmor and seccomp are Linux kernel sandboxing mechanisms that restrict what a process can do by limiting its access to system calls and file operations.

AppArmor is a mandatory access control (MAC) framework that confines programs to a limited set of resources. Policies define which files a process can access, which capabilities it can use, and what network operations are allowed. AppArmor is profile-based and integrated with the filesystem: profiles are simple text files that can be enabled, disabled, or run in audit mode without restarting.

seccomp (secure computing) is a kernel feature that restricts the set of system calls a process can invoke. Filters are defined as bytecode rules that allow or block specific syscalls based on their arguments. seccomp is stricter than AppArmor, once a restricted process attempts a blocked syscall, it either fails with an error or is killed immediately.

Bunker OS Configuration:

Bunker OS is pre-configured with seccomp filters to restrict the system call interface available to its services. For details on which syscalls are restricted and how to customize them, refer to Meta Layers Reference.

Open World Configuration:

Open World has no AppArmor or seccomp configuration by default, allowing full system call access. This is appropriate during development and integration but should be hardened before production deployment.

To enable AppArmor on Open World, the kernel must first be compiled with AppArmor support. Ensure your Open World kernel recipe includes:

CONFIG_APPARMOR=y
CONFIG_APPARMOR_FS=y
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY=y

Additionally, install the userspace AppArmor tools and daemon in the Open World image:

IMAGE_INSTALL:append = " apparmor apparmor-utils"

Verify AppArmor is loaded and enabled in the running Open World:

systemctl status apparmor
cat /proc/cmdline | grep apparmor

To enable AppArmor on a specific service once the system is running:

  1. Add the AppArmor profile for your service to /etc/apparmor.d/ or a subdirectory.

  2. Load the profile: apparmor_parser -r /etc/apparmor.d/your-profile

  3. Put the profile in audit mode first (logs violations, does not block):

aa-complain /etc/apparmor.d/your-profile

  1. Monitor the logs for policy violations:

journalctl -u apparmor -f

  1. Once violations are understood and tuned, move to enforce mode:

aa-enforce /etc/apparmor.d/your-profile

A minimal AppArmor profile for a service might restrict file access and network capabilities:

#include <tunables/global>

/usr/bin/your-service {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  /usr/bin/your-service mr,
  /etc/your-service/** r,
  /var/lib/your-service/ rw,
  /var/lib/your-service/** rwk,

  deny /etc/shadow r,
  deny /root/** rwx,
  deny network,
}

To enable seccomp on a specific service, use a seccomp filter to allow only required syscalls. Unlike AppArmor, seccomp requires kernel-level filter configuration. The recommended approach is to:

  1. Run in audit mode: Let the service run normally and log all syscalls it attempts.

  2. Analyze logs: Identify which syscalls are actually needed.

  3. Generate filter: Create a minimal allow-list of required syscalls.

  4. Test in enforce mode: Apply the filter and verify the service still works.

Tools like seccomp-bpf-helper can assist in generating filters from audit logs. Most container runtimes (Docker, podman) have built-in seccomp support via filter profiles defined in JSON.

A seccomp profile in JSON format might look like:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 1,
  "archMap": [
    {
      "architecture": "SCMP_ARCH_X86_64",
      "subArches": ["SCMP_ARCH_X86", "SCMP_ARCH_X32"]
    }
  ],
  "syscalls": [
    {
      "names": ["read", "write", "open", "close", "stat", "fstat", "lstat", "poll"],
      "action": "SCMP_ACT_ALLOW"
    },
    {
      "names": ["brk", "mmap", "mprotect", "munmap", "mremap"],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Pragmatic hardening strategy for Open World:

  • Development: Run with full access; use Falco monitoring to detect unexpected behavior. AppArmor and seccomp are not enforced.

  • Testing/Integration: Apply AppArmor in audit mode; monitor logs and identify policy violations without blocking. This helps developers understand the service’s actual access patterns before hardening rules are enforced.

  • Pre-Production: Apply AppArmor in enforce mode (or seccomp filters) on non-critical services first. Validate that the service still functions correctly under the restrictions.

  • Production: Apply AppArmor or seccomp in enforce mode on all services; restrict each service to only the syscalls, files, and capabilities it genuinely needs. Combine with Falco monitoring to detect any bypasses or policy violations.