1 / 24

Identification of Covert Channels inside Linux Kernel Based on Source Code

Identification of Covert Channels inside Linux Kernel Based on Source Code. Agenda. Covert channel definition. Possible sources of CCA (Covert Channel Analysis). Methods of CCA in Source Code. Proposed tool to automate CCA on source code of Linux kernel. Conclusion.

tuari
Download Presentation

Identification of Covert Channels inside Linux Kernel Based on Source Code

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Identification of Covert Channels inside LinuxKernel Based on Source Code

  2. Agenda • Covert channel definition. • Possible sources of CCA (Covert Channel Analysis). • Methods of CCA in Source Code. • Proposed tool to automate CCA on source code of Linux kernel. • Conclusion.

  3. Several Definitions of Covert Channels • Definition 1 - A communication channel is covert if it is neither designed nor intended to transfer information at all. • Definition 2 - A communication channel is covert if it is based on transmission by storage into variables that describe resource states. • Definition 3 - Covert channels are those that use entities not normally viewed as data objects to transfer information from one subject to another .

  4. Problem with previous definitions • Does not make it obvious that a covert channel is irrelevant in case of a discretionary security policy (Trojan Horses can anyway leak information via valid system calls). • The previous definitions don’t acknowledge the fact that a covert channel is a result of a specific mandatory security policy being enforced and its implementation.

  5. TCSEC Definition • a communication channel that allows a process to transfer information in a manner that violates the system's security policy. • Given a nondiscretionary (e.g., mandatory) security policy model M and its interpretation I(M) in an operating system, any potential communication between two subjects I(Sh) and I(Si) of I(M) is covert if and only if any communication between the corresponding subjects Sh and Si of the model M is illegal in M.

  6. TCSEC Definition Cont. • The TCSEC is divided into four divisions: D, C, B, and A • An important set of TCSEC requirements, which appears in classes B2 to A1,is that of covert channel analysis (CCA)

  7. Objectives of CCA • Identification of covert channels. • Determination of covert channels' maximum attainable bandwidth. • Handling covert channels using a well-defined policy consistent with the TCSEC objectives. • Generation of assurance evidence to show that all channels are handled according to the policy in force.

  8. Means of Identifying Covert Channels • System reference manuals. • Top-level TCB specification. • Source code.

  9. Methods of Identification in source code • Syntactic Information Flow Analysis. • Semantic Information Flow Analysis. • Shared Resource Matrix Method. • Covert Flow Tree Method.

  10. Syntactic Information Flow • Information Flow is associated with each statement. ex: a:=b  Information flows from b to a if b is not a constant. • Define Flow Policies. • Generate Flow Formulas for the entire TCB. • Use theorem prover. • Check if a flow is real or a false illegal flow.

  11. Semantic Information Flow • Examine all flows visible through a TCB interface and separate the legal from the illegal ones. • Separation of real channels from potential ones must still be done manually. • Separation of potential channels from all the possible flows is labor intensive compared to the above.

  12. Shared Resource Matrix • A matrix containing user visible TCB primitives as rows and read/altered variables which represent attribute of a shared resource as columns is created. • Each entry is marked R or M based on whether the variable is read or modified. • Calculate the transitive closure and update the matrix.

  13. Prototype Design

  14. Module of syntax analysis • Traverse and scan all source code files. • Extract function names and global variables. • Global variables of simple types and complex types • should be accounted for appropriately. • Generate a list of segmented token of the format • <key,value>.

  15. Module of constructing Info Flow Tree • Further code analysis based on Information flow rules. • Readability and Modifiability of shared variables • is analyzed. • If a variable y modifies a variable x then • yx. • If a variable x is read inside a function Fx then • x  Fx.

  16. Info Flow Tree Contd. • If a variable x is modified from inside of a function Fx • then Fx  x. • Compound statements(CSx), Statements(Sx) and • Expressions(Ex) are considered separately . • Null statements, type declaration statements, • goto satements, labelled statements and cont/break • are ignored.

  17. RIFA for Variable Declaration Statements

  18. RIFA for if statements

  19. RIFA for Function Definitions

  20. Sample Code From Linux kernel 2.4.37.9 struct mm_struct * mm_alloc(void) { struct mm_struct * mm; mm = allocate_mm(); if (mm) { memset(mm, 0, sizeof(*mm)); return mm_init(mm); } return NULL; }

  21. Info Flow Tree Creation • Information Flow Trees are created using the • above defined RIFA. • Four types of nodes namely functions, • statements, expressions and variables. • Info Flow tree created as a binary tree.

  22. Generate Info Flow Graph and Shared Resource Matrix • Information Flow tree is transformed into a graph such • that information flows exist across each edge. • Shared resource matrix and its transitive closure is • calculated from the preprocessed information. • The values in the matrix cells are taken as 1,2,3,0.

  23. Conclusion • This tool was used to discover some real covert channels that existed in Linux kernel 2.4.18. • Only entry functions to system calls need be examined. • All the .h files should be analyzed before the .c files. • An automated tool need to be developed to create application scenarios to identify real covert channel from the potential ones.

  24. Bibliography • Virgil D. Gligor (1993). A Guide to understanding Covert Channel Analysis of Trusted Systems. Technical Report NCSC-TG-030, National Computer Security Centre. • Gaoshou Zhai, Yufeng Zhang, Chengyu Liu, Na Yang, MinLi Tian, Hengsheng Yang. Automatic Identification of Covert Channels inside Linux Kernel Based on Source Codes. • Dorothy E. Denning. 1976. A Lattice Model of Secure Information Flow. Communications of the ACM 19, 5 (May 1976), 236-246. • C.R. Tsai, V.D. Gligor, C. S Chandersekaran. 1990. A Formal Method for the Identification of Covert Storage Channels in Source Code. lEEE Transactions on Software Engineering 16, 6 (June 1990), 569-580. • Richard A. Kemmerer. 1983. Shared Resource Matrix Methodology: An Approach to Identifying Storage and Timing Channels. ACM Transactions on Computer Systems 1, 3 (August 1983), 256-277.

More Related