Improving Host Security with System Call Policies

By Niels Provos. USENIX Security Symposium, 2003

575 citations recorded by the source corpus.

View Paper: https://www.semanticscholar.org/paper/2920915f08b926404fabde7b55718b00d8f11420

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

Citations in the corpus

Control-flow integrity (2005, background): “In particular, CFI can contribute to the IRM enforcement of security policies that restrict a program’s use of the underlying operating system (for instance, preventing files with some filenames from being written) [44].”
Preventing Privilege Escalation (2003, background): “Security mechanisms at the operating system level provide ways to reduce the privileges that applications run with [1, 29, 18, 21].”
Native Client: A Sandbox for Portable, Untrusted x86 Native Code (2009, background): “The outer sandbox is substantially similar to prior structures (systrace [50] and Janus [24]) and we will not discuss it in detail in this paper.”
Raksha: a flexible information flow architecture for software security (2007, background): “System calls are infrequent, and interposition has minimal overhead for most workloads [10, 20].”
Dynamic Taint Analysis for Automatic Detection, Analysis, and SignatureGeneration of Exploits on Commodity Software (2005, background): “Systrace [34], GSWTK [18], Tron [7], Janus [19], and MAPbox [3]).”
Dune: Safe User-level Access to Privileged CPU Features (2012, unknown): “A wide range of strategies have been employed to support sandboxing, such as ptrace [16], dedicated kernel modifications [16, 21, 33], binary translation [19], and binary verification [39].”
Iago attacks: why the system call API is a bad untrusted RPC interface (2013, background): “We observe a similar trajectory for system call interposition, which, when introduced, was envisioned as a means for sandboxing arbitrary untrusted applications [10, 11, 24].”
Copilot - a Coprocessor-based Kernel Runtime Integrity Monitor (2004, unknown): “There have been many demonstrations of mandatory access control on the Linux kernel [6, 8, 25, 21, 27, 10]; the latest versions of the Linux kernel contains a Linux Security Modules interface specifically to support these techniques [37].”
SQLrand: Preventing SQL Injection Attacks (2004, background): “Process sandboxing [31] is perhaps the best understood and widely researched area of containing bad code (or its effects), as evidenced by the plethora of available systems like Janus [21], Consh [4], Mapbox [2], OpenBSD’s systrace [33], and the Mediating Connectors [7].”
Information flow control for standard OS abstractions (2007, methodology): “, LSMs [36] an d systrace [27]), but Flume is more closely related to mandatory a ccess control and specifically decentralized information flow con tr l.”
Countering code-injection attacks with instruction-set randomization (2003, background): “Process Sandboxing Process sandboxing [49] is perhaps the best understood and widely researched area of containing bad code, as evidenced by the plethora of available systems like Janus [34], Consh [13], Mapbox [11], OpenBSD’s systrace [53], and the Mediating Connectors [15].”
Lares: An Architecture for Secure Active Monitoring Using Virtualization (2008, methodology): “Techniques such as system call interposition [26] and control flow integrity [1] can be used by such tools.”