Stack inspection and secure program transformations

Bartoletti, Massimo; Degano, Pierpaolo; Ferrari, Gian Luigi

doi:10.1007/s10207-004-0038-8

Cited by 11 publications

(20 citation statements)

References 27 publications

(39 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…There have been several works to optimize stack inspection by eliminating redundant checks with static analysis information [4,12,1,2,10]. Most of them approximate permission sets such as granted permissions and denied permissions [4,12,1,2,10].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Static check analysis for Java stack inspection

Chang

2006

SIGPLAN Not.

View full text Add to dashboard Cite

Abstract. Most static analysis techniques for optimizing stack inspection approximate permission sets such as granted permissions and denied permissions. Because they compute permission sets following control flow, they usually take intra-procedural control flow into consideration as well as call relationship. In this paper, we observed that it is necessary for more precise optimization on stack inspection to compute more specific information on checks instead of permissions. We propose a backward static analysis based on simple call graph to approximate redundant permission checks which must fail. In a similar way, we also propose a backward static analysis to approximate success permission checks, which must pass stack inspection.

show abstract

Section: Introductionmentioning

confidence: 99%

“…Most of them approximate permission sets such as granted permissions and denied permissions [4,12,1,2,10]. Because they compute permission sets following control flow, they usually take intra-procedural control flow into consideration as well as call relationship [12,1,2].…”

Section: Introductionmentioning

confidence: 99%

Static check analysis for Java stack inspection

Chang

2006

SIGPLAN Not.

View full text Add to dashboard Cite

show abstract

“…Unlikely to [1,2], our static analysis is based on simple call graph. The May-Succeed Check Analysis computes checks which may succeed at the entry of each method, which are shown in Figure 3.…”

Section: Theorem 1 For Every Actual Normal Call Chain From a Methods mentioning

confidence: 99%

“…By invoking AccessController.doPrivileged(A), a method M performs a privileged action A; this involves invoking method A.run() with all the permissions of M enabled. This can be seen as marking the method frame of M as privileged: stack inspection will then stop as soon as a privileged frame (starting from the top) is found [2].…”

Section: Stack Inspectionmentioning

confidence: 99%

See 1 more Smart Citation

Visualization of Permission Checks in Java Using Static Analysis

Kim

Chang

Information Security Applications

View full text Add to dashboard Cite

Abstract. The security manager in Java 2 is a runtime access control mechanism. Whenever an access permission to critical resources is requested, the security manager inspects a call stack to examine whether the program has appropriate access permissions or not. This run-time permission check called stack inspection enforces access-control policies that associate access rights with the class that initiates the access. In this paper, we develop a visualization tool which helps programmers enforce security policy effectively into programs. It is based on the static permission check analysis which approximates permission checks statically which must succeed or fail at each method. Using the visualization system, programmers can modify programs and policy files if necessary, as they examine how permission checks and their stack inspection are performed. This process can be repeated until the security policy is enforced correctly.

show abstract

Interprocedural Analysis for Privileged Code Placement and Tainted Variable Detection

Pistoia

Flynn²,

Koved

et al. 2005

ECOOP 2005 - Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. In Java 2 and Microsoft .NET Common Language Runtime (CLR), trusted code has often been programmed to perform accessrestricted operations not explicitly requested by its untrusted clients. Since an untrusted client will be on the call stack when access control is enforced, an access-restricted operation will not succeed unless the client is authorized. To avoid this, a portion of the trusted code can be made "privileged." When access control is enforced, privileged code causes the stack traversal to stop at the trusted code frame, and the untrusted code stack frames will not be checked for authorization. For large programs, manually understanding which portions of code should be made privileged is a difficult task. Developers must understand which authorizations will implicitly be extended to client code and make sure that the values of the variables used by the privileged code are not "tainted" by client code. This paper presents an interprocedural analysis for Java bytecode to automatically identify which portions of trusted code should be made privileged, ensure that there are no tainted variables in privileged code, and detect "unnecessary" and "redundant" privileged code. We implemented the algorithm and present the results of our analyses on a set of large programs. While the analysis techniques are in the context of Java code, the basic concepts are also applicable to non-Java systems with a similar authorization model.

show abstract

Stack inspection and secure program transformations

Cited by 11 publications

References 27 publications

Static check analysis for Java stack inspection

Static check analysis for Java stack inspection

Visualization of Permission Checks in Java Using Static Analysis

Interprocedural Analysis for Privileged Code Placement and Tainted Variable Detection

Contact Info

Product

Resources

About