VisorFlow

Overview

VisorFlow uses virtual-machine introspection to observe system calls, infer information flow, and control confidential data. Under VisorFlow, the system administrator designates some filesystem objects as confidential and some programs as trusted. Any process not loaded from a trusted program will become tainted upon reading a confidential object. The kernel transfers this taint status from process to process as a result of inter-process communication (e.g., an untainted process reads from a tainted process over a pipe). If a tainted process writes to the network, then the kernel sets the packet’s RFC 3514 evil bit; this permits a variety of filtering or spoofing strategies that might help determine the human intentions involved.

VisorFlow architecture

The figure above depicts the components that make up VisorFlow, including:

  1. the Xen hypervisor;
  2. Linux, running in a Dom0 domain;
  3. one or more DomU domains running Linux or Windows;
  4. the VisorFlow security monitor;
  5. one or more processes running within each DomU;
  6. firewalld;
  7. the VisorFlow network engine;
  8. the VisorFlow Windows authorization engine; and
  9. the VisorFlow Linux authorization engine.

Not pictured here is VisorFlow’s network filter.

Consider process Pn in DomU that invokes a system call (a). The act of invoking a system call normally involves the operating system (b), but here it also involves the hypervisor (c) and the VisorFlow security monitor (d). The VisorFlow security monitor observes such system calls and infers how they allow information to flow between processes, and the security monitor’s operating-system engines use these observations to implement a taint-tracking system that resembles SimpleFlow.

In the case of network system calls, the VisorFlow network engine works with Dom0 and the hypervisor to mark as evil packets originating from tainted processes and to taint processes that receive marked packets. For example, if the Linux engine infers that a system call from a tainted process Pn would result in network traffic, the Linux engine would notify the network engine (e). The network engine in turn adds a network filter rule to the host firewall through firewalld, which has the affect of labeling Pn’s packets as evil (f). The added rule involves instructing NetFilter to rely on VisorFlow to actually set the evil bit using the NFQUEUE interface (g). Later, the Linux engine might infer that Pn exited; when this happens, the Linux engine and network engine will remove the firewall rule that labeled Pn’s packets as evil.

Each operating-system-specific engine implements a different model upon which it relies to make decisions about the system. The models encompass:

  • which system calls can cause a process to taint,
  • which system calls can cause an object to become confidential,
  • which system calls can cause the generation of network packets,
  • which processes are tainted, and
  • which objects are confidential (this has to be persistently stored to survive reboots).

This primary advantage of VisorFlow over SimpleFlow is that VisorFlow needs no kernel modifications to operate. This has two important consequences: (1) VisorFlow can mediate closed-source operating systems such as Windows, and (2) VisorFlow avoids difficult-to-maintain modifications to open-source kernels. These advantages come at a performance cost.

By combining aspects of access-control and provenance systems, VisorFlow removes the race conditions found in some provenance systems.

Test VM

After saving the following files to your computer and decompressing them, you can boot the guest using xl create visorflow-guest-linux.cfg. The root password is password.

Disk image
disk.img.gz
Spare disk image
spare.img.gz
Domain configuration (you must modify the paths contained therein to suit your environment)
visorflow-guest-linux.cfg

Related publications

Downloads

The VisorFlow project is also available as a Git repository. To clone the repository, execute

git clone https://www.flyn.org/git/visorflow