CamFlow: Dual Perspectives in Security & Vision

• CamFlow in cloud security is an OS-level framework that enforces information flow control and captures whole-system provenance to enhance data isolation and auditability in Linux-based clouds.
• Its provenance capture system integrates Linux Security Module hooks with NetFilter and relayfs to log system events continuously while managing overhead through selective capture policies.
• In computer vision, CamFlow employs a hybrid motion basis combining interpretable physical bases with stochastic components to robustly estimate 2D camera motion under challenging conditions.

Searching arXiv for relevant CamFlow papers to ground the article in the cited literature. arXiv search query: "CamFlow" CamFlow is the name of two distinct research systems in the arXiv literature. In systems and security, CamFlow denotes an operating-system-level framework for Information Flow Control (IFC) and, subsequently, a whole-system provenance capture mechanism for Linux-based cloud environments (Pasquier et al., 2015, Pasquier et al., 2017). In computer vision, CamFlow denotes a framework for estimating 2D camera motion by representing dense motion fields with hybrid motion bases derived from homography geometry and stochastic components (Li et al., 30 Jul 2025). The shared name does not indicate a shared technical lineage; rather, it designates unrelated projects in different subfields.

1. Nomenclature and scope

The term CamFlow first appears in the cloud-services literature as “CamFlow: Managed Data-sharing for Cloud Services,” where it is introduced as “an OS-level IFC enforcement (a Linux Security Module) plus an IFC-aware middleware” (Pasquier et al., 2015). In that context, CamFlow addresses data isolation, policy-driven sharing, and auditability in multi-tenant cloud platforms. A later systems paper, “Practical Whole-System Provenance Capture,” uses the same name for “a Linux-kernel module (major LSM) plus a small user-space service for capturing and streaming whole-system provenance in a PaaS environment” (Pasquier et al., 2017). The two systems papers are closely related in their use of kernel enforcement and audit mechanisms, but their immediate emphases differ: the earlier work centers IFC enforcement and managed sharing, whereas the later work centers provenance capture and streaming.

Independently, “Estimating 2D Camera Motion with Hybrid Motion Basis” introduces CamFlow as “a novel framework that represents camera motion using hybrid motion bases” (Li et al., 30 Jul 2025). This usage belongs to computer vision rather than operating systems. The underlying problem is “the projection of a camera’s 3D rotation and translation onto the image plane,” and the proposed representation replaces both single-homography and meshflow-style parameterizations with a unified low-dimensional basis expansion (Li et al., 30 Jul 2025).

A common misconception is that all occurrences of CamFlow refer to a single software stack. The arXiv record shows otherwise: the security and provenance systems (Pasquier et al., 2015, Pasquier et al., 2017) and the camera-motion estimator (Li et al., 30 Jul 2025) are separate research efforts that happen to share the same name.

2. CamFlow in cloud security: Information Flow Control

In the cloud-services formulation, CamFlow is motivated by the tension between strong tenant isolation and flexible cross-application data sharing. The paper situates this in a cloud model where “a small number of trusted providers (IaaS)” support “many higher-level PaaS/SaaS tenants,” and where VMs or containers provide only coarse-grained isolation once data is shared across boundaries (Pasquier et al., 2015). Traditional access control is described as insufficient because it checks permissions at enforcement points and then does not govern downstream data movement.

CamFlow addresses this through IFC. Every entity is tagged with secrecy and integrity labels, written as

$\ell(E) = (S(E), I(E)),$

where $S(E) \subseteq T$ and $I(E) \subseteq T$ are sets of tags (Pasquier et al., 2015). The safe-flow condition is defined as a flow $A \rightsquigarrow B$ being allowed iff

$$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$

equivalently $\ell(A) \preceq \ell(B)$ in the lattice $L = 2^T \times 2^T$ (Pasquier et al., 2015). This realizes “no-read-up/no-write-down” for secrecy and “no-read-down/no-write-up” for integrity.

The design is decentralized through privileges associated with tag creation. When a process creates a new tag $t$, it receives four privileges: $t^+_S$, $t^-_S$, $S(E) \subseteq T$0, and $S(E) \subseteq T$1, allowing safe label changes such as declassification and endorsement under explicit privilege possession (Pasquier et al., 2015). The model also includes Conflict of Interest constraints: for a conflict set $S(E) \subseteq T$2, at most one tag from $S(E) \subseteq T$3 may appear in any single process’s labels or privilege sets (Pasquier et al., 2015).

Architecturally, the system comprises “CamFlow-LSM,” trusted processes including a Security Context Manager and IFC Gateway, a user-level API, messaging middleware enforcing IFC on inter-machine flows, and an audit subsystem using relayfs and graph-based analysis tools (Pasquier et al., 2015). The Linux Security Module integration hooks task, inode, socket, pipe, mount, IPC, and capability operations. On each relevant hook, CamFlow performs IFC checks in addition to existing MAC or DAC checks, and failed checks return $S(E) \subseteq T$4 with optional audit logging (Pasquier et al., 2015).

This design suggests that CamFlow’s central contribution in its original domain is not merely policy specification, but continuous enforcement of dataflow constraints across system calls, IPC, and network communication. A plausible implication is that the framework was intended to move cloud security from pointwise authorization toward persistent, system-wide flow semantics.

3. Provenance capture and whole-system auditing

The later systems paper reorients CamFlow toward whole-system provenance. There, provenance is defined as describing “how data came to be in its present form,” including sources and transformations, with applications in forensics, security, and reproducibility (Pasquier et al., 2017). CamFlow is presented as a response to perceived limitations of prior whole-system provenance systems: excessive overhead, dependence on outdated kernels, excessive data generation, or confinement to a single system (Pasquier et al., 2017).

Its implementation uses several kernel facilities. CamFlow “declares itself as a major security module” and relies on LSM hooks so that creation and access events on kernel objects can be observed. Because “the kernel provides no LSM hook on outbound packets,” it also installs a NetFilter hook to record send provenance; inbound packets are observed through socket_sock_rcv_skb (Pasquier et al., 2017). Provenance records are written into relayfs, allowing a user-space daemon to mmap() or read the ring buffer efficiently. Applications may also inject fine-grained subgraphs by writing to /sys/kernel/security/provenance/log (Pasquier et al., 2017).

The in-kernel provenance model treats each kernel object as a sequence of state-versions. “Every time information flows into an object, CamFlow creates a new version node (so the overall graph is acyclic)” (Pasquier et al., 2017). Node records include fields such as node_id, version, object_type, object_id, machine_id, and boot_id; edge records include subject_node_id, object_node_id, and relation_type (Pasquier et al., 2017). Records are binary in-kernel and may be serialized to PROV-JSON in user space.

A key feature is tailoring. Tenants can define an INI-style capture policy specifying whole versus selective capture, targets such as pathnames, UIDs/GIDs, network addresses, control-groups, and LSM security contexts, along with propagation rules and exclusion filters (Pasquier et al., 2017). The example policy includes mode=selective, opaque=directory, track=/home/alice/x, and propagate=0.0.0.0/0:0 (Pasquier et al., 2017). This is explicitly designed to reduce data volume and align capture granularity with application needs.

Provenance is streamed to auditor applications via a user-space daemon, camflow-d, which ships records in batches through middleware such as MQTT, Apache Flume, or Kafka (Pasquier et al., 2017). For distributed settings, each record is stamped with (machine_id, boot_id), and packet entities are identified by the 5-tuple plus TCP sequence number,

$S(E) \subseteq T$5

so that per-machine provenance graphs can be spliced into a distributed provenance graph (Pasquier et al., 2017).

The paper illustrates three auditor applications. Compliance auditing propagates labels over edge types and checks path-based policies, with “≈ 5% CPU” overhead (Pasquier et al., 2017). Intrusion and fault detection is exemplified by FRAPpuccino, which trains on provenance subgraphs in sliding windows and later detects outliers corresponding to vulnerabilities such as “wget arbitrary upload, tcpdump crash, Ruby OOM bug” (Pasquier et al., 2017). Data loss prevention is accelerated through selective capture and 64-bit taint tracking, allowing constant-time taint checks at outbound send points instead of graph traversal (Pasquier et al., 2017).

4. Performance characteristics and systems trade-offs

The IFC-oriented CamFlow reports both OS-level and middleware overheads. On an Intel i7 2.2 GHz machine with 6 GiB RAM and labels containing 20 tags each, sys_clone rises from 57.5 $S(E) \subseteq T$6s natively to 85.9 $S(E) \subseteq T$7s with CamFlow-LSM, described as “∼50% overhead on clone”; sys_pipe rises from 72.7 $S(E) \subseteq T$8s to 86.5 $S(E) \subseteq T$9s with dynamic label allocation, or “∼19% overhead”; and sys_read/write incur “∼5 μs on ~40–62 μs calls ⇒ <10% overhead” (Pasquier et al., 2015). A fixed-size label build option reduces clone and pipe overhead to below 10%. In the middleware benchmark, a 5,000-message publish/subscribe workload increases from 609 ms to 680 ms, or “∼12% overhead,” attributed largely to attribute-level IFC checks on send and receive (Pasquier et al., 2015).

The provenance-capture CamFlow defines percentage overhead as

$I(E) \subseteq T$0

Its LMbench microbenchmarks on an Intel i7 report open/close increasing from 0.88 $I(E) \subseteq T$1s to 1.59 $I(E) \subseteq T$2s in whole mode, “≈ 80% overhead,” and to 1.04 $I(E) \subseteq T$3s in selective mode, “≈ 18%”; stat increases from 0.39 $I(E) \subseteq T$4s to 0.78 $I(E) \subseteq T$5s in whole mode, “≈ 100%,” and to 0.50 $I(E) \subseteq T$6s in selective mode, “≈ 28%”; and fork increases from 110 $I(E) \subseteq T$7s to 116 $I(E) \subseteq T$8s in whole mode, “≈ 6%,” and to 112 $I(E) \subseteq T$9s in selective mode, “≈ 2%” (Pasquier et al., 2017). Macrobenchmarks show 11% overhead for Postmark in whole mode and 6% in selective mode, while Redis operations incur 4–22% overhead under whole capture (Pasquier et al., 2017). A concrete provenance volume example is wget www.google.com, which emits 12.45 kB of PROV-JSON once, reduced to 9.98 kB under selective capture, “≈ 20% reduction” (Pasquier et al., 2017).

These results are accompanied by explicit trade-offs. The provenance paper notes “Completeness vs. volume: selective capture may omit events needed for some queries,” and also identifies open issues around LSM coverage, storage and queries at scale, integration with stream processors, attestation through IMA/TPM, and multi-major-LSM stacking (Pasquier et al., 2017). The earlier IFC paper similarly frames its overheads as acceptable for PaaS workloads, while noting that real workloads usually have fewer tags and less-frequent security-context changes (Pasquier et al., 2015).

5. CamFlow in computer vision: hybrid motion bases for 2D camera motion

In computer vision, CamFlow addresses 2D camera motion estimation, defined as “the projection of a camera’s 3D rotation and translation onto the image plane” (Li et al., 30 Jul 2025). The paper contrasts two pre-existing families of methods. Classical homography methods solve for a single $A \rightsquigarrow B$0 homography matrix $A \rightsquigarrow B$1, which is reliable for planar scenes but degrades under multiple depths or parallax. Meshflow-style methods fit local homographies on an $A \rightsquigarrow B$2 grid and smooth across cells; they can capture mild non-linearity but become difficult to optimize for strong parallax or non-rigid effects (Li et al., 30 Jul 2025).

CamFlow replaces these with a “hybrid motion basis” representation. The dense flow field $A \rightsquigarrow B$3 at pixel $A \rightsquigarrow B$4 is written as

$A \rightsquigarrow B$5

where $A \rightsquigarrow B$6 are 12 physical bases and $A \rightsquigarrow B$7 are stochastic bases (Li et al., 30 Jul 2025). The physical bases are derived by a second-order Taylor expansion of a homographic warp around image coordinates. If a pixel $A \rightsquigarrow B$8 is warped by a homography $A \rightsquigarrow B$9 to $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$0, then the induced flow $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$1 is expanded into basis functions

$$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$2

separately for $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$3 and $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$4, producing $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$5 interpretable flow bases that capture “translation, rotation, scale and simple perspective curvature” (Li et al., 30 Jul 2025).

The stochastic bases span residual nonlinearities. CamFlow draws $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$6 random homography matrices with entries $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$7 and $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$8, converts each to a flow field, and then applies SVD to extract the top $$S(A) \subseteq S(B) \quad \text{and} \quad I(B) \subseteq I(A),$$9 orthonormal components (Li et al., 30 Jul 2025). These represent “a broad set of non-planar motions not well explained by the physical bases” (Li et al., 30 Jul 2025).

A “Motion Estimation Transformer, MET” predicts the coefficient sets $\ell(A) \preceq \ell(B)$0 and $\ell(A) \preceq \ell(B)$1 from a multi-scale feature pyramid built over the input image pair $\ell(A) \preceq \ell(B)$2 (Li et al., 30 Jul 2025). In parallel, a mask subnetwork predicts a per-pixel confidence $\ell(A) \preceq \ell(B)$3, down-weighting regions likely to contain independently moving objects or occlusion. This suggests that CamFlow’s representation is not purely geometric; it is coupled to a learned uncertainty mechanism intended to preserve camera-motion estimation when the scene includes dynamic foreground content.

6. Optimization, benchmark construction, and empirical behavior

CamFlow uses a probabilistic loss based on the Laplace distribution. For predicted flow $\ell(A) \preceq \ell(B)$4, target $\ell(A) \preceq \ell(B)$5, and learned scale parameter $\ell(A) \preceq \ell(B)$6 tied to the confidence mask, the per-pixel negative log-likelihood is

$\ell(A) \preceq \ell(B)$7

Summing over pixels and adding coefficient regularization gives

$\ell(A) \preceq \ell(B)$8

(Li et al., 30 Jul 2025). In practice, the method uses two NLL terms: one on pseudo-motion labels from an off-the-shelf homography estimator and one on photometric consistency of warped deep features, with the balance “automatically at each step” (Li et al., 30 Jul 2025).

Training follows existing unsupervised homography pipelines. Each pair is “randomly cropped to 320×576, converted to grayscale, embedded into a shallow feature space to normalize luminance, and processed at three resolutions” (Li et al., 30 Jul 2025). During training, the mask network suppresses gradients in regions where dynamic foreground is detected by high uncertainty $\ell(A) \preceq \ell(B)$9.

For evaluation, the authors introduce GHOF-Cam. Starting from the GHOF optical-flow dataset, which contains real camera motion plus object motion, they “run SAM to segment cars, people and other dynamic classes, dilate those masks to cover occlusions, and apply them to both images and flow maps,” thereby producing a “camera-motion-only” benchmark for zero-shot evaluation (Li et al., 30 Jul 2025). This benchmark design directly addresses a common ambiguity in camera-motion evaluation: standard optical-flow datasets conflate camera-induced motion with independently moving objects.

The reported results place CamFlow ahead of prior methods across three benchmarks: CAHomo, GHOF, and GHOF-Cam (Li et al., 30 Jul 2025). On CAHomo’s point-matching error, CamFlow reduces the best unsupervised PME from 0.39 for HomoGAN to 0.32 and exceeds classic SIFT+RANSAC in several challenging scenarios, including low-light, low-texture, and large-foreground cases (Li et al., 30 Jul 2025). On GHOF-Cam’s end-point error, CamFlow achieves 1.10 px, improving over MeshFlow at 2.15 px “by nearly 50%” (Li et al., 30 Jul 2025). In foggy, rainy, snowy, and dark scenes, it reports “0.5–1.5 dB PSNR and 0.01–0.05 LPIPS gains over second-best methods,” approaching “GT-Homo” performance (Li et al., 30 Jul 2025).

Ablation results are also explicit. Expanding the basis set from “8→12 physical→24 hybrid yields steadily better accuracy and generalization”; beyond 24 bases, “the returns diminish and inference cost spikes” (Li et al., 30 Jul 2025). The hybrid loss combining motion NLL and photometric NLL outperforms either term alone by “10–20% error reduction on zero-shot tests” (Li et al., 30 Jul 2025). The paper also states two limitations: stochastic bases are sampled offline and fixed, so novel nonlinear artifacts may remain outside the span, and the mask network may suppress useful flow in ambiguous low-signal regions (Li et al., 30 Jul 2025).

A later follow-on paper, CamFlow+, extends this line by adding “depth-translational bases derived from depth and camera intrinsics” and a depth-aware smoothness term, with improved results on GHOF-Cam and video stabilization (Li et al., 4 Jun 2026). This suggests that the 2025 CamFlow formulation established a basis-space view of camera motion that was subsequently generalized to explicit depth-dependent parallax.

7. Comparative interpretation and legacy of the name

The two CamFlow lineages share a methodological pattern despite their disciplinary separation: both replace monolithic representations with structured, compositional ones. In cloud security, CamFlow extends discrete access control into label-based, system-wide flow constraints and detailed provenance graphs (Pasquier et al., 2015, Pasquier et al., 2017). In computer vision, CamFlow replaces a single homography or dense local grid with a low-dimensional basis decomposition combining interpretable geometric components and residual stochastic components (Li et al., 30 Jul 2025).

The name therefore refers not to a single canonical artifact but to a small cluster of unrelated research systems. In the security lineage, CamFlow is associated with IFC enforcement, provenance capture, policy tailoring, stream-oriented auditing, and distributed graph reconstruction (Pasquier et al., 2015, Pasquier et al., 2017). In the vision lineage, CamFlow is associated with hybrid basis representations, transformer-predicted basis coefficients, Laplace-based probabilistic losses, and camera-motion-only benchmarking through dynamic-object masking (Li et al., 30 Jul 2025).

For scholarly usage, precise disambiguation is essential. References to CamFlow in cloud systems should ordinarily be resolved to either the IFC framework (Pasquier et al., 2015) or the whole-system provenance capture mechanism (Pasquier et al., 2017), depending on emphasis. References to CamFlow in computer vision should be resolved to the hybrid motion basis framework for 2D camera motion estimation (Li et al., 30 Jul 2025), with CamFlow+ reserved for the later depth-aware extension (Li et al., 4 Jun 2026).