Policy on François Duthilleul

fapolicyd (File Access Policy Daemon)

Mon, 01 Jan 0001 00:00:00 +0000

fapolicyd (File Access Policy Daemon) is an application allowlisting framework for Linux, developed by Red Hat and shipped as a supported component of RHEL 8+. Its security premise is supply-chain integrity at the execution layer: only software that was installed through a trusted package manager (DNF/RPM) or explicitly declared as trusted by an administrator may execute on the system. An attacker who achieves a foothold and drops a new binary — a reverse shell, a lateral movement tool, a cryptominer — will find that binary blocked at execution time, because it is absent from the trust database, regardless of its Unix permissions or SELinux label. fapolicyd addresses a different dimension of access control than SELinux: SELinux models how applications behave (what resources they may access); fapolicyd models whether applications are trusted at all (whether they may execute in the first place). The two are complementary: SELinux confines a trusted application’s behaviour; fapolicyd prevents untrusted applications from running.

Guardrails

Mon, 01 Jan 0001 00:00:00 +0000

Guardrails are controls wrapped around LLM inference to reduce harmful, non-compliant, or off-policy behavior without replacing the base model. Their objective is AI safety and governance in production: block or rewrite prompts that attempt prompt injection or jailbreaks, filter toxic or leaked PII in outputs, enforce topic allowlists, validate structured tool calls, and log decisions for audit. Guardrails sit on the request path (before tokens reach the model or after the model proposes a draft response), combining rule engines, classifiers, regex, and sometimes smaller models. They complement—not replace—application auth, network policy, and human review; enterprises treat them as mandatory for customer-facing and internal copilots.

OpenShell

Mon, 01 Jan 0001 00:00:00 +0000

OpenShell is an open-source runtime for fleets of autonomous AI agents. An agent is useful because it can read files, run commands, call APIs, and use credentials; that is also the capability profile of a compromised workload. OpenShell leaves the agent free to plan and use tools, and enforces what it may touch outside the model. Three pieces do the work: a gateway manages sandboxes and their policies, a supervisor sits outside the workload and inspects every outbound request, and the sandbox confines the process with kernel controls — Landlock on the filesystem, seccomp on system calls, and user and network namespaces — so the only network path is through the supervisor. Credentials stay outside the agent and are attached only to requests bound for an approved endpoint. Policy is written in YAML, compiled to OPA/Rego, and checked by a prover before a change is applied, so a requested permission can be shown to cross a boundary even if the agent argues that it does not. Denials come back as structured OCSF events rather than silent failures. Prompt guardrails still matter, but they are not the boundary: a model that has been talked into misbehaving keeps whatever credentials it was given unless the runtime never put them there.

PSA (Pod Security Admission)

Mon, 01 Jan 0001 00:00:00 +0000

Pod Security Admission (PSA) is the built-in Kubernetes admission controller that enforces the Pod Security Standards (PSS), a set of predefined security profiles that constrain what a pod is allowed to do. It became stable in Kubernetes 1.25, at which point its predecessor PodSecurityPolicy (PSP) was simultaneously removed. Where PSP was a complex, cluster-scoped object requiring deep RBAC wiring and prone to misconfiguration, PSA is deliberately simpler: it is always enabled, requires no CRDs or RBAC setup, and is configured entirely through namespace labels. The trade-off for that simplicity is that PSA is opinionated and coarse-grained — it enforces fixed profiles rather than arbitrary custom rules, and its granularity is the namespace rather than the individual workload or service account. Teams needing finer-grained policy beyond what PSA offers typically combine it with a policy engine such as Kyverno or OPA Gatekeeper.

SCC (Security Context Constraints)

Mon, 01 Jan 0001 00:00:00 +0000

Security Context Constraints (SCCs) are OpenShift’s mechanism for controlling and enforcing the security posture of pods at admission time. They predate and are more expressive than Kubernetes PSA: where PSA validates a pod spec against a fixed profile and either admits or rejects it, an SCC acts as both a validator and a mutator — it can inject missing fields into the pod spec (a UID from the namespace’s allocated range, an SELinux context, capability drops) so that a pod that did not specify its full security context in its manifest is brought into compliance automatically rather than rejected. SCCs are cluster-scoped resources, and access to them is controlled via RBAC: a service account must be granted use of an SCC through a Role or ClusterRole binding before pods running under that service account can be admitted with the permissions that SCC grants.

USBGuard

Mon, 01 Jan 0001 00:00:00 +0000

USBGuard is a security framework for Linux that controls which USB devices are permitted to interact with the system. It sits above the kernel’s native USB authorisation subsystem — a per-device authorisation flag in the USB core that determines whether a device can be configured and begin sending data — and enforces a policy defined in a rule file against every device that connects or is present at startup. The threat model USBGuard addresses is both insider threat (unauthorised storage devices, data exfiltration) and hardware attack: BadUSB devices — malicious firmware embedded in devices that present themselves as HID keyboards, network adapters, or other trusted classes — can be blocked by a sufficiently specific USBGuard policy that restricts which USB interface classes are permitted. A USB device that claims to be a keyboard (03:01:01) but was not explicitly authorised cannot send keystrokes; a USB storage device plugged into a workstation with a policy that only allows a specific keyboard and mouse is blocked outright. USBGuard cannot protect against devices present at boot (before the daemon starts), so it is a defence-in-depth control for the running OS rather than a substitute for physical port security.