Sandboxing: Understanding System Containment

Monday, November 29, 2010

Jamie Adams


I recently attended the 24th Large Installation System Administration (LISA) Conference in San Jose, California.

I met so many great people including Matt Olander, the Chief Technology Officer of iXsystems and a member of FreeBSD Project’s Marketing and Public Relations teams. Matt has been a long time BSD advocate and he was previously the Director of IT at BSDi.

His enthusiasm and in-depth knowledge of Berkeley Software Distribution (BSD) history was impressive. Moreover, his knowledge of its reliability aspects, code base management, security, and upcoming release information was equally impressive. He talked to me for a few minutes on camera which I will release in another post.

Later that evening, I reflected on the long history of BSD and its innovative contributions. In particular, I thought about the FreeBSD jail mechanism and its contributions to system survivability through the concept of containment.

I also thought about all of the incarnations of technologies aimed at providing some level of containment. As a foundation of explaining these technologies to my sales and marketing team, I felt it necessary to explain the concept of containment and how it relates to system survivability.

Because of my years of service in the United States Navy, I think of system survivability as being analogous to ship survivability.

Visualize a ship's internal layout as a honeycomb. Each cell, or compartment, can be sealed off from another in case of compromise. If one compartment begins to flood, the hatches (doors) can be closed to prevent adjacent compartments from flooding. In effect, the flood is contained and the ship can continue its mission.

In information technology, most people grasp the concept of network segregation through use of virtual local area networks (VLAN), routing, and firewalls but the containment idea seems to be lost when it is applied to a collection of operating systems running in virtual guests on a single platform.

Even more confusing is the idea of containment within a single operating system by segregating processes or groups of processes to serve as a single application.

Consider a hardware- or software-based virtualized system which is running many virtualized guests. Each guest could be running a separate operating system. If you think of each guest as a compartment on the ship, you must think about how you can contain one guest if it is compromised during an attack or suffers a catastrophic failure.

Of course, these guests can't be completely isolated because they will need some shared resource (e.g., oxygen) or possibly a means to communicate with another compartment. Just like in a ship, each compartment serves a purpose but interacts with other compartments to serve the entire ship.

Likewise, in a virtualized system architecture, the access control points between compartments and to the outside world must be managed appropriately for survivability.

Within each guest resides an operating system running one or more applications such as a database or a web service. Similarly, ship compartments serve various purposes such as navigation, fire control, or propulsion.

In both situations, it makes sense to not “put all of your eggs in one basket” in case of catastrophic failure. So, you should at least have a redundant compartment if possible.

If a single guest operating system were running two web services, wouldn't it make sense to have them buffered from each other? For example, ensure that a compromise to one of them doesn't jeopardize the other.

Likewise, if a ship's compartment had two pieces of equipment and one caught fire or had an electrical failure shouldn't it be insulated enough to protect the other equipment?

The value of containment should be obvious by now. Yet, I haven't mentioned the most important characteristics of containment technologies – that is to be simple in design and easily managed. Complex configurations can result in an inconsistent configuration which translates into improper containment and an uncertain security posture.

In the Navy, the term “Material Conditions” is defined by Naval Warfare Publication (NWP) 3-20.31 as a ship's configurations representing varying degrees of closure (hatches being opened or closed among other things). The material condition of readiness is set according to the degree of threat to the ship and the current operational directives.

Examples of operational directives would be day-to-day operations as opposed to being in a combat situation. These conditions establish the fighting integrity of the ship and maintain its survivability.

In the simplest form, the aforementioned hatches provide access into the compartments and containment when necessary. Each door is adorned with a symbol such as a big black letter 'Y' enclosed in a black ring — referred to as “Circle Yoke.”

When a ship's readiness is set, all of the respective hatches marked with that level and below are secured. More importantly, many traditional hatches have eight dogs (levers) which must be secured in a specific order for the hatch to be completely sealed (locked down).

A more simplified hatch such as the QAWTD has a single mechanism to secure all of its levers at once in order to simplify and expedite the establishment of the required readiness level.

If you think of the hatches (doors) as access control points in a system, such as discretionary access controls, mandatory access controls, host-based firewall rules, or the grouping of processes, the easier it is for an administrator to configure and understand them, the better.

This may help when establishing the operational directive for a public facing web server that will likely be configured differently (tighter) than an internal web server due to the risk of attack involved.

The idea of containment within an operating system is sometimes referred to as sandboxing. Some of the more popular technologies specifically designed to accomplish this come to mind: FreeBSD jails, Solaris Containers (including Solaris Zones), and SUSE Linux's AppArmor.

Security-Enhanced Linux (SELinux) is full implementation of mandatory access controls (MAC) and is capable of Multilevel Security (MLS). Although it wasn't designed specifically for containment, it certainly can be used for this purpose and several policies delivered with Red Hat-based systems accomplish this out-of-the-box.

There are more technologies available but an organization should weigh a technology's capabilities against the mission requirements or “directives.” You should then ultimately consider the ease of deployment and manageability.

In my opinion, the easiest technologies to implement are FreeBSD jails, Application Armor (AppArmor), and then Solaris Containers (including Solaris Zones).

Cross-posted from Security Blanket Technical Blog

Possibly Related Articles:
Operating Systems
Operating Systems Linux LISA sandboxing VLAN
Post Rating I Like this!
Robert Gezelter Jamie,

Nicely written, particularly the detailed description of shipboard containment. I have long used similar metaphors in describing the needs of security in systems and networks, notably in my chapters in the "Computer Security Handbook" and the "Handbook of Information Security".

I will note that nested isolation regimes predate the use of the term "sandbox" The present Wikipedia entry for "sandbox" has no references, but I distinctly remember the term first gaining popularity well into the Internet era.

By contrast, multi-user protection regimes that restricted non-privileged users to impacting the system and other users, are traceable far further back, certainly to Multics and the antecedents of IBM's VM/CMS, both of which date from the early 1960's. Certainly, Digital's RSX-11 family and OpenVMS (nee VAX/VMS) had highly effective multi-user protection regimes in place in the late 1970's that prevented users from interfering with the system or each other. In the case of OpenVMS, this included detailed control of privileges and full access controls on different objects.

However, the term "sandbox" was never used in this context. Some documents referred to "brickwall" protection between user processes and the system; and "multi-user protection" was commonplace.
Lynn Wheeler virtual machine reference from late 60s & early 70s, in addition to "sand box" was "padded room". reference from long ago and far away:
Lynn Wheeler ... virtual machines provided partitioning and containment ... but still allowed individuals to shoot themselves in the foot. some of the virtual machine based online timesharing service bureaus (an earlier "cloud" paradigm) added features to the virtual machine environment to help prevent their uses from (also) "shooting themselves in the foot."
Lynn Wheeler current genre of mainframes offer both virtual machine operating system and a subset of the virtual machine features supported directly by the hardware (not requiring additional software) called LPARs. Standard production environments (even w/o virtual machine operating systems) are normally configurated with environments that are regularly referred to as "sand box" and/or "test".
Lynn Wheeler trivia: some number of the CTSS people went to the science center on 4th flr and did the cp67 precursor to vm/cms (some number then left science center and did some of the early virtual machine based timesharing service bureaus); others from CTSS went to the 5th flr and did Multics.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.