A Rose by Any Other Name or an Insane Root? Adventures in Name Resolution

Namespaces are fundamental to computing systems. Each namespace maps the names that clients use to retrieve resources to the actual resources themselves. However, the indirection that namespaces provide introduces avenues of attack through the name resolution process. Adversaries can trick programs into accessing unintended resources by changing the binding between names and resources and by using names whose target resources are ambiguous. In this paper, we explore whether a unified system approach may be found to prevent many name resolution attacks. For this, we examine attacks on various namespaces and use these to derive invariants to defend against these attacks. Four prior techniques are identified that enforce aspects of name resolution, so we explore how these techniques address the proposed invariants. We find that each of these techniques are incomplete in themselves, but a combination could provide effective enforcement of the invariants. We implement a prototype system that can implement these techniques for the Linux file system namespace, and show that invariant rules specific to each, individual program system call can be enforced with a small overhead (less than 3%), indicating that fine-grained name resolution enforcement may be practical.

[1]  Robert N. M. Watson,et al.  Capsicum: Practical Capabilities for UNIX , 2010, USENIX Security Symposium.

[2]  Ken Thompson,et al.  Plan 9 from Bell Labs , 1995 .

[3]  Xiang Cai,et al.  Exploiting Unix File-System Races via Algorithmic Complexity Attacks , 2009, 2009 30th IEEE Symposium on Security and Privacy.

[4]  David A. Wagner,et al.  Analyzing inter-application communication in Android , 2011, MobiSys '11.

[5]  Crispan Cowan,et al.  StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks , 1998, USENIX Security Symposium.

[6]  Manuel Costa,et al.  Bouncer: securing software by blocking bad input , 2008, WRAITS '08.

[7]  Alan J. Hu,et al.  Fixing Races for Fun and Profit: How to Use access(2) , 2004, USENIX Security Symposium.

[8]  Sam Weber,et al.  Verifying the EROS confinement mechanism , 2000, Proceeding 2000 IEEE Symposium on Security and Privacy. S&P 2000.

[9]  Paul A. Karger,et al.  An Augmented Capability Architecture to Support Lattice Security and Traceability of Access , 1984, 1984 IEEE Symposium on Security and Privacy.

[10]  Calton Pu,et al.  A Methodical Defense against TOCTTOU Attacks: The EDGI Approach , 2006 .

[11]  Matt Bishop,et al.  Checking for Race Conditions in File Accesses , 1996, Comput. Syst..

[12]  Niels Provos,et al.  Improving Host Security with System Call Policies , 2003, USENIX Security Symposium.

[13]  Norman Hardy,et al.  The Confused Deputy: (or why capabilities might have been invented) , 1988, OPSR.

[14]  Bill Cheswick,et al.  Firewalls and internet security - repelling the wily hacker , 2003, Addison-Wesley professional computing series.

[15]  M. E. Crandall,et al.  Names , 1924, Living I Was Your Plague.

[16]  Li Gong,et al.  A secure identity-based capability system , 1989, Proceedings. 1989 IEEE Symposium on Security and Privacy.

[17]  Robert M. Marmorstein,et al.  A Tool for Automated iptables Firewall Analysis , 2005, USENIX Annual Technical Conference, FREENIX Track.

[18]  David R. Cheriton,et al.  The V distributed system , 1988, CACM.

[19]  HardyNorm The Confused Deputy , 1988 .

[20]  Norman Hardy,et al.  KeyKOS architecture , 1985, OPSR.

[21]  Tomer Hertz,et al.  Portably Solving File TOCTTOU Races with Hardness Amplification , 2008, FAST.

[22]  Robert N. M. Watson,et al.  A taste of Capsicum , 2012, Commun. ACM.

[23]  Shai Halevi,et al.  Where Do You Want to Go Today? Escalating Privileges by Pathname Manipulation , 2010, NDSS.