740 research outputs found
Robusta: Taming the Native Beast of the JVM
Java applications often need to incorporate native-code components for efficiency and for reusing legacy code. However, it is well known that the use of native code defeats Java's security model. We describe the design and implementation of Robusta, a complete framework that provides safety and security to native code in Java applications. Starting from software-based fault isolation (SFI), Robusta isolates native code into a sandbox where dynamic linking/loading of libraries is supported and unsafe system modification and confidentiality violations are prevented. It also mediates native system calls according to a security policy by connecting to Java's security manager. Our prototype implementation of Robusta is based on Native Client and OpenJDK. Experiments in this prototype demonstrate Robusta is effective and efficient, with modest runtime overhead on a set of JNI benchmark programs. Robusta can be used to sandbox native libraries used in Java's system classes to prevent attackers from exploiting bugs in the libraries. It can also enable trustworthy execution of mobile Java programs with native libraries. The design of Robusta should also be applicable when other type-safe languages (e.g., C#, Python) want to ensure safe interoperation with native libraries.Engineering and Applied Science
50 years of isolation
The traditional means for isolating applications from each other is via the use of operating system provided “process” abstraction facilities. However, as applications now consist of multiple fine-grained components, the traditional process abstraction model is proving to be insufficient in ensuring this isolation. Statistics indicate that a high percentage of software failure occurs due to propagation of component failures. These observations are further bolstered by the attempts by modern Internet browser application developers, for example, to adopt multi-process architectures in order to increase robustness. Therefore, a fresh look at the available options for isolating program components is necessary and this paper provides an overview of previous and current research on the area
Transparent code authentication at the processor level
The authors present a lightweight authentication mechanism that verifies the authenticity of code and thereby addresses the virus and malicious code problems at the hardware level eliminating the need for trusted extensions in the operating system. The technique proposed tightly integrates the authentication mechanism into the processor core. The authentication latency is hidden behind the memory access latency, thereby allowing seamless on-the-fly authentication of instructions. In addition, the proposed authentication method supports seamless encryption of code (and static data). Consequently, while providing the software users with assurance for authenticity of programs executing on their hardware, the proposed technique also protects the software manufacturers’ intellectual property through encryption. The performance analysis shows that, under mild assumptions, the presented technique introduces negligible overhead for even moderate cache sizes
HasTEE: Programming Trusted Execution Environments with Haskell
Trusted Execution Environments (TEEs) are hardware-enforced memory isolation
units, emerging as a pivotal security solution for security-critical
applications. TEEs, like Intel SGX and ARM TrustZone, allow the isolation of
confidential code and data within an untrusted host environment, such as the
cloud and IoT. Despite strong security guarantees, TEE adoption has been
hindered by an awkward programming model. This model requires manual
application partitioning and the use of error-prone, memory-unsafe, and
potentially information-leaking low-level C/C++ libraries.
We address the above with \textit{HasTEE}, a domain-specific language (DSL)
embedded in Haskell for programming TEE applications. HasTEE includes a port of
the GHC runtime for the Intel-SGX TEE. HasTEE uses Haskell's type system to
automatically partition an application and to enforce \textit{Information Flow
Control} on confidential data. The DSL, being embedded in Haskell, allows for
the usage of higher-order functions, monads, and a restricted set of I/O
operations to write any standard Haskell application. Contrary to previous
work, HasTEE is lightweight, simple, and is provided as a \emph{simple security
library}; thus avoiding any GHC modifications. We show the applicability of
HasTEE by implementing case studies on federated learning, an encrypted
password wallet, and a differentially-private data clean room.Comment: To appear in Haskell Symposium 202
The Price of Safety in an Active Network
Security is a major challenge for "Active Networking," accessible programmability creates numerous opportunities for mischief. The point at which programmability is exposed, e.g., through the loading and execution of code in network elements, must therefore be carefully crafted to ensure security. The SwitchWare active networking research project has studied the architectural implications of various tradeoffs between performance and security. Namespace protection and type safety were achieved with a module loader for active networks, ALIEN, which carefully delineated boundaries for privilege and dynamic updates. ALIEN supports two extensions, the Secure Active Network Environment (SANE), and the Resource Controlled Active Network Environment (RCANE). SANE extends ALIEN's node protection model into a distributed setting, and uses a secure bootstrap to guarantee integrity of the namespace protection system. RCANE provides resource isolation between active network node users, including separate heaps and robust time-division multiplexing of the node. The SANE and RCANE systems show that convincing active network security can be achieved. This paper contributes a measurement-based analysis of the costs of such security with an analysis of each system based on both execution traces and end-to-end behavior
- …