Drawing the red line in Java

Back, Godmar; Hsieh, Wilson C.

doi:10.1109/hotos.1999.798387

Cited by 25 publications

(24 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…al. [4] encourages a single, explicit separation between trusted and untrusted code, which they call "the red line." Our motivation is similar, but we propose a separation between multiple security layers, with a small kernel of truly trusted functionality.…”

Section: Secure Language Subsets and Isolationmentioning

confidence: 98%

Retaining sandbox containment despite bugs in privileged memory-safe code

Cappos

Dadgar

Rasley

et al. 2010

Proceedings of the 17th ACM Conference on Computer and Communications Security

View full text Add to dashboard Cite

Flaws in the standard libraries of secure sandboxes represent a major security threat to billions of devices worldwide. The standard libraries are hard to secure because they frequently need to perform low-level operations that are forbidden in untrusted application code. Existing designs have a single, large trusted computing base that contains security checks at the boundaries between trusted and untrusted code. Unfortunately, flaws in the standard library often allow an attacker to escape the security protections of the sandbox.In this work, we construct a Python-based sandbox that has a small, security-isolated kernel. Using a mechanism called a security layer, we migrate privileged functionality into memory-safe code on top of the sandbox kernel while retaining isolation. For example, significant portions of module import, file I/O, serialization, and network communication routines can be provided in security layers. By moving these routines out of the kernel, we prevent attackers from leveraging bugs in these routines to evade sandbox containment. We demonstrate the effectiveness of our approach by studying past bugs in Java's standard libraries and show that most of these bugs would likely be contained in our sandbox.

show abstract

Section: Secure Language Subsets and Isolationmentioning

confidence: 98%

Retaining sandbox containment despite bugs in privileged memory-safe code

Cappos

Dadgar

Rasley

et al. 2010

Proceedings of the 17th ACM Conference on Computer and Communications Security

View full text Add to dashboard Cite

show abstract

“…With respect to the general area of mobile code security research, recent papers published by researchers at the University of Utah [2][18] argue, as we believe, that the software techniques being applied to mobile code security need additional functionality. The papers argue for stronger separation than that provided by existing techniques -that mobile code execution environments need protection models similar to those employed in operating system software and that these are not only important for code protection and separation but also for resource management and communication.…”

Section: Technology Transfermentioning

confidence: 99%

Extensible Operating System Security

Hollingworth¹,

Redmond²,

Rice³

2002

View full text Add to dashboard Cite

REPORT DOCUMENTATION PAGE Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to

show abstract

“…We divide KaffeOS into user and kernel parts [1], an important distinction used in operating system design. A user/kernel distinction is necessary to maintain system integrity in the presence of process termination.…”

Section: Process Separationmentioning

confidence: 99%

Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java

Back¹,

Hsieh²,

Lepreau³

2000

View full text Add to dashboard Cite

Single-language runtime systems, in the form of Java virtual machines, are widely deployed platforms for executing untrusted mobile code. These runtimes provide some of the features that operating systems provide: inter-application memory protection and basic system services. They do not, however, provide the ability to isolate applications from each other, or limit their resource consumption. This paper describes KaffeOS, a system that provides these features for a Java runtime. The KaffeOS architecture takes many lessons from operating system design, such as the use of a user/kernel boundary.The KaffeOS architecture supports the OS abstraction of a process in a Java virtual machine. Each process executes as if it were run in its own virtual machine, including separate garbage collection of its own heap. The difficulty in designing KaffeOS lay in balancing the goals of isolation and resource management against the goal of allowing direct sharing. Overall, KaffeOS is up to 11% slower than the freely available JVM on which it is based, which is an acceptable penalty for the safety that it provides. KaffeOS is substantially slower than commercial JVMs, but exhibits much better performance scaling in the presence of uncooperative code.

show abstract

Drawing the red line in Java

Cited by 25 publications

References 14 publications

Retaining sandbox containment despite bugs in privileged memory-safe code

Retaining sandbox containment despite bugs in privileged memory-safe code

Extensible Operating System Security

Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java

Contact Info

Product

Resources

About