This article is the second in a three-part series that provides a technical overview of Decoy File System (DcyFS). This original research was recently showcased in a paper titled “Hidden in Plain Sight: Filesystem View for Data Integrity and Deception,” which appeared at the 15th Conference on Detection of Intrusions and Malware & Vulnerability Assessment (DIMVA) in Paris in June 2018.

Our previous blog post introduced the concepts underpinning the overall design of Decoy File System (DcyFS) as part of using cyber deception tactics to protect against attacks on networked environments. Central to its security and deceptive capabilities is DcyFS’s ability to modulate subject trust through a hierarchical file system organization that explicitly encodes trust relations between different execution contexts.

The core principle of DcyFS’s trust model is that of least privilege, which means that legitimate subjects only require access to directories, files and file types relevant to their work and do not need to know about other files on the system. In this post, we detail how a trust model based on this principle is built into DcyFS’s architecture and describe its effects on process execution.

DcyFS’s Architecture

The core component of DcyFS is a set of security domains that provides each process with a customized view of the file system computed as the union of the base file system and its overlay (see Figure 1).

Figure 1: Architectural overview of DcyFS

To alter the resulting union between layers, each overlay has the ability to:

1. Hide base files;
2. Modify their content by overlaying a different file with the same name; and
3. Inject new files into the overlay that are not present in the original host system.

File writes are stored in the overlay, protecting base files from being overwritten. This forms the basis of a stackable file system that can be mounted atop different base file system types (e.g., block, network) to offer data integrity protection and detection of attacks that aim to tamper with or steal data.

To separate file system views, DcyFS transparently combines two file systems, which we term the “base” file system and the “overlay” file system. The base file system is the main host file system and is read-only, while the overlay is a read-write file system that can control what is visible to a running process.

When a file with the same name appears in both file systems, the one in the overlay is visible to the process. When a directory appears in both file systems, both directories’ contents are merged in the process view. A file or directory is hidden from view by injecting a character device on the overlay. To hide a base file or directory, DcyFS simply marks it as deleted in the overlay.

Decoy files are similarly placed in carefully chosen locations inside the overlay mount, and existing files can further be replaced or redacted for cyber deception.

Creating Security Domains to Isolate Views

To implement the separation between the base layer and its overlays, DcyFS creates persistent and reusable security domains to transparently isolate file system views. Security domains enforce coherent views of the file system and form the basis for defining DcyFS’s trust model. Each security domain has its own profile, which contains the list of files and directories that are viewable within that domain. These include files that are deleted, replaced or injected in the domain view.

The Trust Model

DcyFS’s file system view isolation is policy-driven, defined by associations between mount namespaces, file system objects and users with security domains. Similar to data classification models, each security domain sd ∈ (Γ, ≤) is assigned a rank denoting its level of trust relative to the other domains. Security domains, therefore, comprise a partially ordered lattice (Γ) ordered by trust scores (≤), with the untrusted domain (sd_unt) at the bottom denoting untrusted execution and the root domain (sd_root) at the top denoting trusted execution. Meet operation U denotes greatest lower bound, which is used to determine the proper domain of execution of new programs. DcyFS uses this model to determine in which security domain to execute new processes.

This decision point extends the semantics of the kernel’s exec(filename, args) function to compute the following parameters:

• Target execution domain as sd_filename U sd_args U sd_user U sd_ns.
• The meet between the security domains of filename, args computed across all arguments denoting file paths.
• User, the set of security domains associated with a user.
• ns, the parent process’ security domain, denoted by the current mount namespace.

Including sd_ns in the security domain determination of a newly launched process limits its execution to its parent process’ security domain, thus preventing lower-ranking domains from accidentally or maliciously spawning child processes in higher-ranking domains. In our research implementation, this property is seamlessly encoded in the security domains’ mount namespace hierarchy.

To illustrate, Figure 2 describes a simple security domain setup for a client desktop. It includes domains to separate internet-facing applications (sd_browser), word processing tools (sd_docs) and programming environments for scripted languages (sd_scripts).

In this context, a web browser running in sd_browser may download a PDF document from the internet, which gets stored in the browser domain. To visualize its contents, a trusted user (sd_root) opens the file in a PDF viewer (sd_docs). As a result, DcyFS executes the viewer in the browser domain — the greatest lower bound of the domains involved in the security domain determination — so that the potentially malicious PDF file has no access to the user’s documents (kept separated in sd_docs).

Similarly, if a process running in sd_scripts spawns a second process not authorized to execute in the scripts domain, DcyFS moves the subprocess task to the untrusted domain (sd_unt). This is to protect against attacks where a trusted process (e.g., Bash) is exploited to install and launch untrusted malware. The rule also prevents malware from gaining entry to another security domain by running trusted applications.

Figure 2: Security domains lattice example

Root Domain

The root domain is a special mount namespace that fuses together a writable base file system mount with all the read-only overlay file system mounts from the other domains into a single, unified view. This enhances usability by overcoming merging issues that arise from DcyFS’s ability to separate file system views.

The root domain is reserved for a few special programs — such as a file browser, terminal, file copying tools and object collisions when multiple overlays share the same fully qualified object path names — and handled by stacking overlays according to the trust order relative to each domain.

Since the file system is a combination of the base file system and the overlays of the other domains, the file browser can transparently open files and launch applications in their native security domains to help protect the integrity of the root domain. Furthermore, specialized copying tools allow files to be copied or moved between domains as desired.

Blinding Attackers With File System Opacity

DcyFS leverages its overlay infrastructure to conceal its existence from attackers and curtail access to explicit information about its kernel modules, configuration objects and overlay mounts. This is achieved by bootstrapping the file system with configuration rules that hide and redact specific file system objects.

For example, /proc/mounts (/proc/self/mount* and /etc/mtab are redacted to conceal overlay mount point information and bind mounts into the overlays. As a result, DcyFS’s kernel live patch and kernel module are hidden from file system views. Similarly, the file system hides its configuration, usermode helper components (e.g., decoy generation, configuration parsing, forensics data extraction) and working directory where overlays and logs persist in the base file system.

File System Denial and Cyber Deception

DcyFS provides data integrity by strictly enforcing a policy that all writes are made to the overlay layer and never to the underlying base. Writes to base files are first copied up to the overlay layer before being written using copy-on-write. This has the desirable effect of preserving the integrity of the base file system. Changes made by untrusted processes do not affect the base, protecting legitimate users from seeing malicious changes as well as effectively keeping a pristine copy of the file system that can revert to the point immediately before the malicious process started.

DcyFS can hide specific files and directories from a user or a process to help protect against sensitive data leaks. Additionally, the file system can generate encrypted files and implant decoys in the overlay to shadow sensitive files in the base file system. DcyFS transparently monitors and logs access to files classified as more sensitive, confidential or valuable. Moreover, only the untrusted process is affected by hidden and decoy files, leaving legitimate users free of any effects or confusion.

It is worth noting that trusted processes can also benefit from security domains. DcyFS can launch a trusted process atop an overlay to hide unnecessary files and directories or inject decoys to catch potential insiders. Furthermore, certain directories can be bind mounted from the base file system to give trusted processes the ability to directly view and modify them. For example, we might run a database server, providing it with a fake overlay view of the entire file system, but giving it direct write access to the directories in which it writes data. As a result, if the database application is compromised, damage is limited to the data directory only.

[skyword_iframe src=”//www.youtube.com/embed/21ovDIj29nU?autoplay=0&start=0″ width=”560″ height=”315″ ]

A Look Forward

We envision security domains being configured using standard operating system policies, similar to how SELinux policies are shipped with Linux, to mitigate potential security weak points that can result from manual configuration. Default policies could also be attached to software installed from app stores, or repositories such as Linux’s package managers. In the future, we plan to investigate ways to automate this process through the application of different notions of trust (e.g., policy-, reputation-, and game-theoretic-based).

Finally, a word about portability. Our initial implementation was developed for Linux to leverage its virtual file system capabilities and mature mount namespace implementation. Recently, Windows Server 2016 has been released with native namespace support and an overlay file system driver mirroring its open-source counterpart. This new release could facilitate the future realization of DcyFS’s architectural blueprint for Windows-based environments.