An information flow control model for C applications based on access control lists

Abstract

Access control within an application during its execution prevents information leakage. The prevention can be achieved through information flow control. Many information flow control models were developed, which may be based on discretionary access control (DAC), mandatory access control (MAC), label-based approach, and role-based access control (RBAC). Most existing models are for object-oriented systems. Since the procedural C language is still in use heavily, offering a model to control information flows for C applications should be fruitful. Although we identified information flow control models that can be applied to procedural languages, they do not offer the features we need. We thus developed a model to control information flows for C applications. Our model is based on access control lists (ACLs) and named CACL. It offers the following features: (a) controlling both read and write access, (b) preventing indirect information leakage, (c) detailing the control granularity to variables, (d) avoiding improper function call, (e) controlling function call through argument sensitivity, and (f) preventing change of an application when the access rights of the application’s real world users change. This paper presents CACL.

Introduction

During the execution of an application, users can access information managed by the application (e.g., users can read an application’s output). In an application that manages sensitive information, preventing information leakage is important. Information leakage refers to leaking high security level information to low security level users. For example, if a patient of a hospital obtains case histories of other patients that can only be read by the hospital’s doctors, information leakage occurs. To prevent information leakage, information flows should be controlled. An information flow occurs when information is assigned to a variable (although many definitions exist for information flows, they are more or less similar to our definition). Controlling information flows corresponds to preventing high security level information from being assigned to variables that can be accessed by low security level users. Since variables of an application generally store an application’s information and users can obtain a variable’s content when the variable is output, controlling information flows prevents low security level users from obtaining high security level information when variables are output.

When an application is being executed, real world users play roles in the application. A user playing a role may access the variables that can be accessed by the role. Therefore, controlling information that can be accessed by roles during the execution of an application prevents information leakage. The control corresponds to information flow control, which is a language-based security issue (Sabelfeld and Myers, 2003) because an information flow control model should be embedded in a programming language to implement secure applications.

Many information flow control models are available. Existing models may be based on discretionary access control (DAC) (Bertino et al., 1998, Ferrari et al., 1997, Maamir and Fellah, 2003, Samarati et al., 1997), mandatory access control (MAC) (Bell and LaPadula, 1976, Brewer and Nash, 1989, Denning, 1976, Denning and Denning, 1977), label-based approach (McCollum et al., 1990, McIlroy and Reeds, 1992, Myers, 1999, Myers and Liskov, 1997, Myers and Liskov, 1998, Myers and Liskov, 2000), and role-based access control (RBAC) (Chou, 2004a, Chou, 2004b, Chou, 2004c, Izaki et al., 2001). Most existing models are for object-oriented systems. In our opinion, developing an information flow control model for the procedural C language would be valuable because the language is still in use heavily. Although we identified information flow control models that can be applied to procedural languages (Myers, 1999, Myers and Liskov, 1997, Myers and Liskov, 1998, Myers and Liskov, 2000), they do not offer the features we need. We thus developed a model to control information flows for C applications. It is based on access control lists (ACLs) and named CACL. CACL ensures secure access of information within C applications. It controls both read and write access. Although most existing information flow control models merely obey the “no write down” rule (Bell and LaPadula, 1976) to control write access and more precise write access control may decrease the flexibility of information flow control, we insists that write access should be controlled precisely. The rationale is that write operation is destructive. If write access is not controlled precisely, data may be corrupted according to improper write operations. We propose that only the data sources trusted by a variable can write the variable. CACL offers the following features (since C functions cannot be instantiated, some dynamic features such as dynamic adaptation to object state change mentioned in Chou, 2004d is unnecessary):

• Control both read and write access as described above.

• Prevent indirect information leakage (Myers, 1999, Myers and Liskov, 1997, Myers and Liskov, 1998, Myers and Liskov, 2000). For example, suppose the subject “sbj1” is allowed to read the object “obj2”, “sbj2” is allowed to read “obj1”, but “sbj1” is not allowed to read “obj1”. Then, the content of “obj1” may leak to “sbj1” via “obj2” when “sbj1” read “obj2” after “sbj2” read “obj1” into “obj2”. To prevent the leakage, after “sbj2” reads “obj1” into “obj2”, the access rights of “obj2” should be changed to prevent “sbj1” from reading “obj2”.

• Detail the control granularity to variables. Information of an executing application is generally stored in its variables. Since different variables may be in different security levels (Varadharajan and Black, 1990), they should be protected independently. That is, the control granularity should detail to variables.

• Avoid improper function call. The research in Varadharajan and Black (1990) proposed that different methods in an object may be in different security levels and therefore should be protected independently. According to this consideration, different functions in a C application may also be in different security levels and therefore should be protected independently. For example, in a bank system, the function “changeBalance” can only be invoked by the function with administrator privilege. Other functions are not allowed to invoke the function. In this regard, avoiding improper function call is necessary.

• Control function call through argument sensitivity. For example, suppose that a customer of a bank can change his password by invoking the bank’s function using the variable “newPasswd” as an argument. Then, using other variables such as the customer’s account as an argument in the function call should be denied. The rationale is that different variables carry different information for different purposes. Note that type checking in programming languages cannot solve the problem because the legal and illegal arguments may be of the same type. For example, if the attribute “newPasswd” and the customer’s account are of the same type “int”, using the customer’s account as an argument in the above example will pass type checking.

• Prevent changing an application when the access rights of the application’s real world users change. An ACL is generally composed of an object, multiple subjects, and the type of access rights (e.g., read, write, and execute). If subjects in ACLs are real world users, ACLs changes when the access rights of real world users change (e.g., when a real world operator is promoted to a manager, his access right should change). If ACLs are organized as above, changing the access rights of an application’s real world user results in changing the application (because ACL is a part of the application). In fact, the model in (Myers, 1999, Myers and Liskov, 1997, Myers and Liskov, 1998, Myers and Liskov, 2000) suffers from this problem, as will be described in Section 2.

When designing CACL, we encountered many problems. In the rest of this paper, we first survey related work. Next, we describe the problems we encountered and the solutions we proposed. We then present CACL and its evaluation.