Sandbox (computer security)

Introduction

Computer users most often have to choose between functionality and security, but recent technology is changing this. Linux systems and free BSD systems are the likely possible future direction for operating systems because of the emphasis on security. On a traditional operating system, intruders use buffer overload, Trojans, backdoor access techniques, and vulnerabilities in shared libraries to steal personal information and passwords (Zhao). This stolen confidential data can consist of e-mail addresses, business trade secrets, and financial records (Zhao). With a sandbox, we do not need to worry about key loggers or spy-ware jeopardizing our machine. In addition, sandboxes can also limit the amount of damage poorly designed software such as trial software can do. We can spend less time worrying about securing their system. Definition of a Sandbox and Rationale: In order to design a sandbox properly, we need to understand the parts of an operating system. There are two parts of the operating system, the kernel and the extensions or modules. These modules consist of a set of instructions independent from the kernel that is loaded dynamically after the kernel is booted. The goal of a sandbox is to keep the extensions separate from the kernel. These instructions are associated with device drivers, file systems, system calls, network drivers, TTY, and executable interpreters. Most Linux system crashes are because of extensions that are not reliable in every situation. When a program crashes, it creates a fault that can lead to further disruption of the system. To prevent unreliable extensions causing faults, limitations must be imposed (Karygiannis). The solution is a sandbox, which provides a protected, limited environment where the applications can be run without posing a threat to the system. Examples of programs that cause threats are web browsers. For example, Firefox 2.0.0.1 once had a memory management error where information could be disclosed through cache collisions (Alcazar). Firefox is not a core part of the operating system; it is an application. Having programs that interact with a web browser is a great security risk. An intruder could obtain control of the animation programs such as flash or media players that connect to the internet and have cross-domain rendering or vulnerabilities in products such as Adobe Acrobat Reader (Alcazar). For a period of time, Ghost-script PS viewers were so dangerous that many people were afraid to put them on their computers (Alcazar). Studies confirm that users do dangerous things because they are either unwilling to take the necessary precautions or are uneducated. Many do not know how to configure programs like web browsers properly, and many people are unwilling to stop using products such as P2P programs that provide dangerous access to their computers. Once dangerous programs allow spy-ware into the system such as a key logger, many users do not know that their computers have spy-ware on them that has access to most files. An ideal operating system using modularity with sandboxes makes it easier to add products without either worrying what the software contains or whether the user has configured it correctly when setting it up.

Protection against Intrusion Providing Motive for Sandbox

Kevin Mitnick's book The Art of Intrusion, a book written by a former famous hacker who turned into a security expert, informs the reader about the horror of zero day exploits. He states that even being diligent about updating patches and security is not enough. Another hacker says that once a hacker finds vulnerabilities in a product, the hacker spreads word of the vulnerability to his trusted friends in a chat room. Although the discoverer may or may not attack other's systems, the people who know about the exploit may use it to break into other people's computers. Since security companies do not know about the vulnerability at this stage, most people are unable to detect that someone has intruded into their system. It can take a long time for the security companies to detect that people are exploiting the vulnerability and then it takes more time to come up with an appropriate workaround. Mitnick writes, "Because there is always a potential to be compromised by a zero-day exploit, every organization using the flawed product is vulnerable until a patch, or workaround is released. So how do you mitigate the risk of this exposure? I believe the only viable solution lies in using a defense in depth model. We must assume that our publicly accessible computer systems will be vulnerable to a zero-day attack at some point in time. Thus, we should create an environment which limits the potential damage a bad guy can do." The solution is a sandbox that provides a protected, limited environment where applications can run without the possibility of damaging to other parts of the system that hosts them. This means that processes should have restricted access to valuable resources such as registers. Also other control panel functions should be unavailable to the process (Tech Encyclopedia). Users or their trusted programs can easily create and maintain sandboxes. At run time, sandboxes can be reconfigured and any changes made dynamically reconfigure the processes immediately. A good analogy to use is a computer within a computer.

Difficulty of Policy Making

Sandboxes provide a centralized means of creating policies tailored to individual programs and confining the application to enforced policies. One of the topics relating to sandbox creation is how to make policies that are enforce in such that all users are satisfied. One implementation is a role-based implementation for every application on the computer. This is a predefined method that each program should act, based on an online database. Should the program act differently than the database describes, the sandbox places the misbehaving process in jail (Gong). A sandbox system can use an implementation of the tripwire file system. This idea is borrowed from McAfee and Norton’s smart firewalls. Much like the firewalls, sandboxes work by granting or denying access permissions to programs the sandbox contain. An interesting design question is, where should the mechanisms be located that enforce sandbox imposed restrictions? The problem with sandboxes is that they sometimes can give false positives. This can be a problem when a programming firm creates a new version of their software and need to delete the old piece of software. The software needs access to the registers in order to do this. Sun Microsystems has spent many years implementing sandboxes into their Java Virtual Machines, also called the Java run time environments, to contain the downloaded code (Carter). Original sandboxes were once very strict but now programmers have developed ones that are more efficient (Carter). In more modern versions of Java virtual machine, once the code is determined to be safe then it has more freedom to execute and can even execute outside the sandbox. The benefit of this is to reduce the overhead cost of speed (Carter).

Design Considerations

When designing a sandbox, there are many questions to ask. Some of these questions consist of whether entities are passive or active. In addition, the question the developer needs to answer is whether the sandboxes are transient or persistent entities. In addition, do these entities function as lightweight disposable containers or do they maintain relatively static associations (Peterson). An ideal system predicts system calls to prevent delays caused by the performance of security checks (Peterson). This is still in the research phase because everyone has different expectations of how software should interact. The performance of security checks causes overhead and delays. This can slow the computer down considerably when several calls are sent such as when the computer boots. Sometimes multiple calls can appear as of a denial of service attack by creating large numbers of sandboxes until all memory is exhausted. Sandbox related objects might also occupy kernel memory that cannot be paged. Most of the research in developing sandboxes is oriented around composing algorithms to more accurately predict signals and therefore reduce wait time. There are several qualities a designer must implement into a sandbox to ensure its effectiveness. It must have multithread support because many malicious threats have several independent actions that exist in parallel (ZDnet). The fact that there are multiple threads helps thwart any action from security mechanisms such as anti-virus. A sandbox can map all of the child processes and then throw an exception if a process is acting suspiciously (Carter). Another quality a sandbox should have is the ability to detect threads injected into remote processes. When threats take over an operating system, the threats often inject its own thread into running processes. This way, they can be more difficult to identify when they camouflage themselves as normally occurring processes (ZDnet). Another concern is that criminals may harvest e-mails so they can obtain the addresses and either harass the senders or sell the information to other people who will harass the senders.

Basic Tactics of Intruders

Another thing a sandbox watches is network communication. Many intruders are aware that most people do not configure their peer-to-peer or P2P software correctly and so the criminal may attempt to spread worms through this system. When a person downloads software with an interesting name that contains a virus, the sandbox because of emulation will be able to catch this. The sandbox should be able to detect other internet services such as news group services. They can monitor POP3, DNS, IRC, and others through this mechanism. Instant messaging communication can run code but only within the confined system. This makes the system safer. While sandboxes are good for letting a person know that they have mal-ware operating on their computer, they still should have the traditional anti-virus and anti-spy ware to remove the malware (ZDnet). An intruder can run unhelpful processes to gain access to file. An ideal example of this is the Name Service Cache Daemon. This utility can be used by glibc to retrieve entries from /etc/passwd and /etc/groups through inter-process communication over a UNIX domain socket. By knowing these tactics, one can design a sandbox that can keep these malicious acts from occurring.

Address Checking for Validity of Processes

Andrew Tanenbaum, an operating systems pioneer describes more about the design of sandboxes. He suggests that for a 32-bit address space, we could divide it up into 256 sandboxes on 16-MB boundaries so all addresses within a sandbox have a common upper 8 bits. In addition, one could have 512 sandboxes on 8-MB boundaries, with each sandbox having a 9-bit address prefix. The sandbox size should be chosen to be large enough to hold the largest applet without wasting too much virtual address space. Tanenbaum states that physical memory for paging on a modern computer is not a concern. He suggests having two sandboxes to prevent self-modifying code. Recently, a security expert spoke to the Ohio State Senate about how electronic elections were bad because it is possible for a virus to change the results of an election and have another thread destroy the virus so it is impossible to detect the virus existed (Curtis). A sandbox can potentially correct this because as soon as a program is loaded, it would start its sandbox, then checks determine if all code and data references are confined to the appropriate sandbox. This means that JMP and CALL functions are carefully examined to see that the target location is within the sandbox (ZD net).

If the process has code that runs outside of the range of a sandbox, the process is rejected. One of the most concerning things to monitor, for are dynamic JMP statements. These statements require that the registers are checked at run-time. To safeguard the registers, the sandbox first copies the code into a safety register called s1. Then the code is shifted the appropriate number of times for its prefix, then the next prefix is loaded into another register. If they do not match, the process is terminated (ZD net).

Log Files

Other mechanisms use sandboxes to protect files such as log files that are often modified to hide one’s intrusion and so the intruder can come back and interfere with the computer (Scout). Because the file is protected, the security tools can identify an intrusion and block the person’s IP address as well as notify the user. In addition, files are protected such as etc/rcX.d that holds the configuration of the system in Linux (Scout). Ensuring the safety of log files adds an additional layer of accountability within an operating system to keep the system more secure.

Monitoring Paths

One of the major ways that file systems are protected is by monitoring paths. Paths are caused by the flow of information (Mosberger). They are useful because they allow partial processing of the path processing function. One of the ways that mal-ware makers sneak their programs onto a computer is to have several components and then combine them so that they interact with another piece of software. Multiprogramming allows two components to be put in main memory (Mosberger). Sandboxes can keep track of when programs of when executions are to execute in real time by checking the number of corrections and if something is suspicious, it can detain the processes. Another way that paths can be improved is for programmers to build modular applications using as small a number of threads as possible. By limiting the configurations to static configurations, the programmer can reduce the time of building of an application and make it easier to update the applications (Mosberger). By using an enforced standard for connecting a program to an operating system, the sandbox can detect a rogue process easier.

Paging

Consideration of paging within a sandboxed operating system can improve security. Programs that run under circumstances that cause the program to be unreliable can cause faults. Most of this instability is caused by invariants which are expressions that do not change when a computer program runs (Scout). Sometimes, because there is a lack of standards, an operating system comes across an invariant which it does not understand (Scout). To keep the system safe and secure, it is necessary to remove invariants that can cause faults (Scout). Most invariants are caused when web pages require certain software to interact with web browsers such as different flash players. In order to reduce the risks posed by a fault, it is necessary to implement the envelope policy that running operating systems with sandboxes offer. This works by loading the code necessary for an application to run into its own fault domain (Wahbe). The goal of recent research done in this area is to make fault tolerance so cheap in processing time and memory that designers can ignore its performance costs to choose what modules to put processes in so they can have their own fault domains. This can be a challenge if there is much dataflow coming from a process. The best way to stop faults is to use the sandbox implementation to examine jumps and calls. Conclusion: Designing an operating system that has a monitor attached to each sandbox ensures an improved experience. For example, these monitors can monitor applications that start the process or attach to that process during run time. Another thing that sandboxes could monitor are memory resources, which are the amount of physical memory each process consumes. The sandbox could also watch what network resources the process requests. The sandbox needs to make dynamic decisions about what resources the programs are allowed to view (Carter). In addition, monitors can monitor interrupts. Lastly, the monitor can monitor the swapping of pages. This can be done by monitoring with callbacks, which consist of multimedia timers that now can be triggered for a billionth of a second with very high accuracy. In addition, process monitors are employed which monitor each process so one cannot take up a surprising amount of resources. By keeping a system accountable, we can lock up the system to make valuable information unavailable to those who wish to intrude a system for malicious reasons. Seasoned hackers would argue that this is the only way to protect a system against the tools that are available today for scanning vulnerabilities.

External Link

http://developer.novell.com/wiki/index.php/Novell_AppArmor

http://www.sandboxie.com

Works Cited

Mosberger, David "Scout: A Path Based Operating System" 1997 DISS <historical.ncstrl.org>

Peterson, Dave <http://sandbox.sourceforge.net/>

Gong, Li, Mueller, Marrine, "Going Beyond the Sandbox: An Overview of the Architecture in the Java Runtime Environment 1.2"

Schilit, BN. Adams, N. Want, R. "Context Aware Computing Applications" 1994 USENIC