From Languages to Systems: Understanding Practical Application Development in Security-typed Languages

Hicks, Boniface; Ahmadizadeh, Kiyan; McDaniel, Patrick

doi:10.1109/acsac.2006.30

Cited by 32 publications

(26 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Several informationflow tools have been developed for mainstream languages, e.g., Java-based Jif [35], Caml-based FlowCaml [46], and Ada-based SPARK Examiner [8], [11], as well as case studies [46], [3], [23], [13], [12], [15], [38]. Informationflow analysis is becoming particularly attractive for web applications (e.g, [13], [12], [49], [30]), where the challenge is to secure the manipulation of secret and public data on both server and client side.…”

Section: Introductionmentioning

confidence: 99%

Dynamic vs. Static Flow-Sensitive Security Analysis

Russo

Sabelfeld

2010

2010 23rd IEEE Computer Security Foundations Symposium

155

216

View full text Add to dashboard Cite

Abstract-This paper seeks to answer fundamental questions about trade-offs between static and dynamic security analysis. It has been previously shown that flow-sensitive static information-flow analysis is a natural generalization of flowinsensitive static analysis, which allows accepting more secure programs. It has been also shown that sound purely dynamic information-flow enforcement is more permissive than static analysis in the flow-insensitive case. We argue that the step from flow-insensitive to flow-sensitive is fundamentally limited for purely dynamic information-flow controls. We prove impossibility of a sound purely dynamic information-flow monitor that accepts programs certified by a classical flow-sensitive static analysis. A side implication is impossibility of permissive dynamic instrumented security semantics for information flow, which guides us to uncover an unsound semantics from the literature. We present a general framework for hybrid mechanisms that is parameterized in the static part and in the reaction method of the enforcement (stop, suppress, or rewrite) and give security guarantees with respect to terminationinsensitive noninterference for a simple language with output.

show abstract

Section: Introductionmentioning

confidence: 99%

Dynamic vs. Static Flow-Sensitive Security Analysis

Russo

Sabelfeld

2010

2010 23rd IEEE Computer Security Foundations Symposium

155

216

View full text Add to dashboard Cite

show abstract

“…One may wonder how our results with JLift speak to Jif programming as it is done today, as Jif has been used to build several substantial systems, including JPMail, a mail client [12] and a Civitas, remote voting system [7]. The answer is simple: the programmer must work around the imprecision of various analyses in order get the program to type check.…”

Section: Discussionmentioning

confidence: 99%

Implicit Flows: Can’t Live with ‘Em, Can’t Live without ‘Em

King

Hicks

et al. 2008

Information Systems Security

Self Cite

View full text Add to dashboard Cite

Abstract. Verifying that programs trusted to enforce security actually do so is a practical concern for programmers and administrators. However, there is a disconnect between the kinds of tools that have been successfully applied to real software systems (such as taint mode in Perl and Ruby), and information-flow compilers that enforce a variant of the stronger security property of noninterference. Tools that have been successfully used to find security violations have focused on explicit flows of information, where high-security information is directly leaked to output. Analysis tools that enforce noninterference also prevent implicit flows of information, where high-security information can be inferred from a program's flow of control. However, these tools have seen little use in practice, despite the stronger guarantees that they provide.To better understand why, this paper experimentally investigates the explicit and implicit flows identified by the standard algorithm for establishing noninterference. When applied to implementations of authentication and cryptographic functions, the standard algorithm discovers many real implicit flows of information, but also reports an extremely high number of false alarms, most of which are due to conservative handling of unchecked exceptions (e.g., null pointer exceptions). After a careful analysis of all sources of true and false alarms, due to both implicit and explicit flows, the paper concludes with some ideas to improve the false alarm rate, toward making stronger security analysis more practical.

show abstract

“…Jif policy consists of a principal hierarchy and the Jif policy model enforces the -property and simple security property over that hierarchy [Hicks et al 2006]. The hierarchy defines a partial order on all the principals used in a particular application.…”

Section: Analyzing Jif Policy In Palmsmentioning

confidence: 99%

A logical specification and analysis for SELinux MLS policy

Hicks

Rueda

Clair

et al. 2010

ACM Trans. Inf. Syst. Secur.

Self Cite

View full text Add to dashboard Cite

The SELinux mandatory access control (MAC) policy has recently added a multilevel security (MLS) model which is able to express a fine granularity of control over a subject's access rights. The problem is that the richness of the SELinux MLS model makes it impractical to manually evaluate that a given policy meets certain specific properties. To address this issue, we have modeled the SELinux MLS model, using a logical specification and implemented that specification in the Prolog language. Furthermore, we have developed some analyses for testing information flow properties of a given policy as well as an algorithm to determine whether one policy is compliant with another. We have implemented these analyses in Prolog and compiled our implementation into a tool for SELinux MLS policy analysis, called PALMS. Using PALMS, we verified some important properties of the SELinux MLS reference policy, namely that it satisfies the simple security condition andproperty defined by Bell and LaPadula. We also evaluated whether the policy associated to a given application is compliant with the policy of the SELinux system in which it would be deployed.

show abstract

From Languages to Systems: Understanding Practical Application Development in Security-typed Languages

Cited by 32 publications

References 23 publications

Dynamic vs. Static Flow-Sensitive Security Analysis

Dynamic vs. Static Flow-Sensitive Security Analysis

Implicit Flows: Can’t Live with ‘Em, Can’t Live without ‘Em

A logical specification and analysis for SELinux MLS policy

Contact Info

Product

Resources

About