A Formal Verification Method for SELinux Security Policies Based on KFramework

Abstract

The present invention discloses a formal verification method for selinux security policies based on the KFramework. The semantic framework Kframework is used to perform formal modeling on the selinux security policy language. K is a rewrite-based executable semantic framework in which programming languages, type systems, and formal analysis tools can be defined using configurations and rules. By using the syntax parsing function provided by the KFramework, the policy configuration source file is processed, and then by using its semantic execution function, the security properties of the policy are analyzed and verified. Moreover, the written syntax and semantics can be reused to verify multiple security models, greatly simplifying the work required for policy verification. The method is simple, low-cost, and highly reliable, effectively improving the problem-solving efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software verification, and in particular to a formal verification method for selinux security policies based on KFramework. Background Art

[0002] SELinux (Security Enhanced Linux) security policy:

[0003] In the field of access control, a running program, or a process and thread in memory is called a subject, and an object operated by the subject, or a general file resource is called an object;

[0004] In traditional access control, that is, discretionary access control, access control of an object is implemented according to the identity of the subject and the group to which it belongs. That is, the concepts of user and program are not distinguished, and users only rely on programs not created by themselves to perform operations on the computer. That is to say, there is no real permission management for users.

[0005] SELinux is a classic implementation of mandatory access control. Access control is implemented by the operating system or system administrators, and the goal is to limit the ability of a subject to perform a certain operation on an object. Whenever a subject attempts to access an object, the operating system kernel will enforce the authorization rules - check security attributes and decide whether access is allowed. There will be corresponding authorization rules for any operation of any subject on any object, and no user can override or modify the policy. The policy defined by the security administrator can be guaranteed to be enforced on all users in principle.

[0006] As a classic MAC implementation case, SELinux has been incorporated into the upstream Linux kernel for many years, and SELinux is also set to be enabled by default on some Linux distributions that pursue stability and security.

[0007] The existing technologies are as follows:

[0008] Extract security properties according to the security model, write corresponding policy analysis tools according to the security properties, first process the policy file, parse the policy statements, and then verify its properties by establishing models, etc. In summary, the defects of the existing technologies are as follows:

[0009] 1) The existing verification technologies for selinux policies mainly write analysis tools for the security model and then verify the policy with the analysis tools;

[0010] 2) The analysis tools written for a specific security model often have too strong pertinence and lack generality;

[0011] 3) In the process of writing the analysis tool, the work of parsing the policy file has a lot of repetitiveness. Summary of the Invention

[0012] The present invention is a formal verification method for selinux security policies based on KFramework, designed to address the deficiencies of existing technologies for verifying SELinux policies and similar security policies. By utilizing the syntax parsing function provided by KFramework, the policy configuration source file is processed, and then by using its semantic execution function, the security properties of the policy are analyzed and verified. Moreover, the written syntax and semantics can be reused to verify multiple security models, greatly simplifying the work required for policy verification. The method is simple, low-cost, and highly reliable, effectively improving the problem-solving efficiency. The present invention is implemented through the following technical solutions:

[0013] The present invention discloses a formal verification method for selinux security policies.

[0014] S1. Model the selinux security policy language and sort out the BNF grammar.

[0015] S2. Define the syntax of the selinux security policy language in KFramework. The defined syntax of the selinux security policy language is the syntax statement in K Framework written according to the BNF grammar of the selinux security policy language.

[0016] S3. Using the defined selinux security policy syntax in KFramework as a carrier, formalize the semantics of the selinux security policy language through the meaning of the statements in the selinux security policy language and write it out in the form of configuration items and rewrite rules in KFramework.

[0017] S4. Obtain the security model.

[0018] S5. Obtain the security attributes and corresponding constraints that need to be concerned about according to the security model.

[0019] S6. Write the corresponding specifications in K according to the security attributes and constraints to obtain the specification code in K.

[0020] S7. Compile the syntax statement part obtained in S2, the semantic part written in the form of configuration items and rewrite rules obtained in S3, and the specification part obtained in S6 into K code through (the compiler kompile provided by K) to obtain the semantic execution environment of the selinux security policy language.

[0021] S8. Obtain the source code of the selinux security policy to be verified.

[0022] S9. Take the selinux security policy source code as the input of the semantic execution environment obtained in S8, perform semantic execution, and obtain the semantic execution result;

[0023] S10. Judge whether the security attribute is satisfied according to the semantic execution result, and obtain the verification result.

[0024] As a further improvement, in steps S1, S2, and S3 of the present invention, formal modeling of selinux is performed at the language level, and the syntax and semantics of the selinux policy language are clearly described in a unified language (K code).

[0025] As a further improvement, the syntax of the selinux policy language in step S2 of the present invention and the meaning of the statements in the selinux security policy language in step S3 are obtained from the documents or manuals provided by selinux official to ensure their correctness.

[0026] As a further improvement, the security model in step S5 of the present invention needs to have a clear formal description, including the state variables in the model and the constraint relationships between the state variables.

[0027] As a further improvement, the security attribute in step S6 of the present invention is the constraint relationship of the state variables in the model.

[0028] As a further improvement, the specification in step S6 of the present invention is an additional supplement to the original configuration items and rewrite rules.

[0029] As a further improvement, the selinux security policy source code that needs to be obtained in step S8 of the present invention is a single-file source code that has been macro-expanded and conforms to the selinux security policy syntax.

[0030] As a further improvement, the result of the semantic execution in step S9 of the present invention is programmed with the final state of the configuration item. If there are still unprocessed statements in the configuration item, it means that the statement does not meet the specification written according to the security attribute in S6.

[0031] The beneficial effects of the present invention are as follows:

[0032] The semantic framework K framework is adopted to formally model the selinux security policy language. K is a rewrite-based executable semantic framework in which programming languages, type systems, and formal analysis tools can be defined using configurations and rules. Configurations organize states in units called cells, which are tagged and can be nested. K rewrite rules specify which parts of a term are read-only, write-only, read-write, or unused. This makes K suitable for defining truly concurrent languages, even in the presence of sharing. Computations are represented as syntactic extensions of the original language's abstract syntax, and sequentialization of computational tasks (such as program fragments) is performed using nested list structures. Computations are like any other term in the rewrite environment: they can be matched, moved from one place to another, modified, or deleted. This makes K suitable for defining control-intensive features such as abrupt termination, exceptions, or call / cc.

[0033] From the language level, formal modeling of the selinux security policy is carried out, with a higher level of abstraction, ignoring the parts of the selinux security policy implementation that are strongly coupled to the operating system kernel, and only focusing on the security properties of the policy itself.

[0034] The descriptions of the syntax and semantics of the obtained selinux policy language in K can be reused and can be used in multiple security models, with high generality.

[0035] If the verified security policy does not meet the constraints of the security model, the obtained semantic execution environment can accurately locate the problem. Brief Description of the Drawings

[0036] Figure 1 Represents the complete operation flowchart of the present invention;

[0037] Figure 2 Represents the schematic diagram of the device structure of the present invention. Detailed Description of the Invention

[0038] The present invention discloses a method and device for analyzing and verifying selinux security policies based on the K Framework, including:

[0039] 1. Formally model the selinux policy language according to the syntax and statement meaning of the selinux policy language, and describe it in the form of unified K code;

[0040] 2. Extract the security properties and corresponding constraints from the security model to be verified, and also describe them in K code to obtain the specifications of the security model;

[0041] 3. Compile the K code (including syntax, semantics, specifications) part to obtain the semantic execution environment of the selinux policy language;

[0042] 4. Use the security policy of SELinux to be verified as the input of the semantic execution environment, perform semantic execution, and obtain the execution result;

[0043] 5. Analyze the verification result according to the semantic execution result;

[0044] The technical solution of the present invention will be further described below with reference to the accompanying drawings of the specification and through specific embodiments:

[0045] A method for analyzing and verifying SELinux policies based on the K Framework, which is characterized in that the syntax tree parsing and semantic execution functions of the K Framework are used to parse the SELinux policy configuration file and verify the security properties. The method specifically includes the following steps:

[0046] A1. Model the SELinux security policy language and sort out the BNF grammar;

[0047] A2. Define the syntax of the SELinux security policy language in the K Framework. The defined syntax of the SELinux security policy language is the syntax statement in the K Framework written according to the BNF grammar of the SELinux security policy language;

[0048] A3. Using the defined SELinux security policy syntax in the K Framework as the carrier, formalize the semantics of the SELinux security policy language through the meaning of the statements in the SELinux security policy language, and write it out in the form of configuration items and rewrite rules in the K Framework;

[0049] A4. Obtain the security model;

[0050] A5. Obtain the security attributes to be concerned about and the corresponding constraints according to the security model;

[0051] A6. Write the corresponding specifications in K according to the security attributes and the corresponding constraints to obtain the specification code in K;

[0052] A7. Compile the K code (including the previously obtained syntax part, semantic part, and specification part) through the compiler kompile provided by K to obtain the semantic execution environment of the SELinux security policy language;

[0053] A8. Obtain the source code of the SELinux policy to be verified;

[0054] A9. Use the source code of the SELinux security policy as the input of the semantic execution environment obtained in step 8 to perform semantic execution and obtain the semantic execution result;

[0055] A10. Determine whether the security attribute is satisfied according to the semantic execution result, and obtain the verification result.

[0056] Figure 2 This represents the structural schematic diagram of the device of the present invention. The present invention also discloses a formal verification device for selinux policies based on the K Framework, including

[0057] The K Framework, an executable semantic framework for formally modeling the selinux policy language;

[0058] Modeling of the selinux policy language, including the BNF grammar and semantics of the selinux policy language;

[0059] The selinux policy language syntax parser, completed in K, for parsing the selinux policy source code to generate a syntax tree;

[0060] The selinux policy language semantic execution environment, completed in K, for semantically executing the selinux policy source code in K;

[0061] The selinux semantic execution result analyzer, used to analyze the semantic execution result and obtain the verification conclusion.

[0062] Among them, the formal description of the selinux policy language in steps A1, A2, and A3 will be presented in the form of K code in the K Framework;

[0063] For the syntax and statement meanings of the selinux policy language required for formally modeling the selinux policy language in steps A1, A2, and A3, they should be obtained from the selinux official documentation or manual; The syntax in K must be written in its specific format, that is, the syntax statement in K.

[0064] The syntax statement in K is divided into two parts on the left and right

[0065] syntax Boolean::="true"|"false"

[0066] The left side is a sort, which can be understood as the syntax type in K. The right side defines a production. A production can have two types, constructor and function. Writing semantics is writing constructor.

[0067] The syntax of the syntax statement in K follows the rules of the BNF grammar. Therefore, the statement can be first sorted into the BNF grammar and then written in the form in K.

[0068] The steps of writing semantics can be roughly divided into:

[0069] 1. Select statements and organize the structure of the statements

[0070] 2. Write the structure of the statements in BNF grammar

[0071] 3. Convert the BNF grammar into the form of constructors in K

[0072] The configuration items in K can be understood as various state variables during the program execution. If the program execution is regarded as a process of Turing machine state transition, then the significance of the configuration items lies in setting the initial stages of various states, and the final state of the configuration items represents the result of the program execution.

[0073] The steps of setting configuration items can be roughly divided into:

[0074] Sort out the state variables that need to be concerned in the selinux policy configuration

[0075] Determine the data structure and initial values that the state variables should have

[0076] Write the configuration items

[0077] The semantics of the selinux policy language in K can be presented through rewrite rules. The rewrite rules in K can be understood as simple replacements, similar to the process of symbolic execution. K will match the rewrite rules for each syntax unit during execution. If there is a successfully matched rule, it will be reduced according to the rule until there is no rule that can be successfully matched and the execution ends.

[0078] The steps of writing semantics can be roughly divided into:

[0079] Determine the syntax units to be processed. Here, the syntax units must be productions defined by the syntax statement

[0080] Determine the state variables affected by the semantics and their next states

[0081] Write rewrite rules for the syntax units and state variables

[0082] Determine the constraint conditions required by the semantics

[0083] Supplement the requires statement according to the reduction conditions

[0084] The security model in step A5 needs to have a clear formal description, including the state variables in the model and the constraint relationships between the state variables.

[0085] The security attributes in step A6 are the constraint relationships of the state variables in the model.

[0086] The specifications in step A6 are additional supplements based on the original configuration items and rewrite rules.

[0087] A security model models a security system, describes a system that is always secure, and includes a finite state machine where each state meets the security requirements. A security property is a property of the security model.

[0088] The steps to write security properties in the specifications of K can be roughly divided into:

[0089] Obtain security properties according to the requirements of the security model

[0090] Determine the state variables or configuration items on which various security properties depend

[0091] Convert security properties into relationships or constraints between state variables or configuration items

[0092] Describe the constraints between state variables in logical language

[0093] Write the logical description of the constraints as a requires statement or a rewrite rule. The compiler kompile used in step A7 of compilation is built into KFramework and can compile K code into kore intermediate code.

[0094] The selinux security policy source code to be obtained in step A8 is a single-file source code that has been macro-expanded and conforms to the selinux security policy syntax.

[0095] The obtained selinux policy source code will be used as the input for semantic execution.

[0096] K will finally use the final state of the configuration item as the result of semantic execution. If all statements are correctly reduced, the k cell will finally be empty, indicating that all specifications have been correctly processed in some way. Otherwise, it means that there is a statement that does not conform to the specification, that is, the next statement in the k cell.

[0097] Selinux policy statement structure diagram:

[0098] class <class_name> [inherits <common_name>] [{<perm_set>}]

[0099] where

[0100] [] indicates that the content inside is optional

[0101] [] indicates non-terminals, and the rest indicate literals

[0102] Introduction to Key Concepts

[0103] sort in K represents a syntactic category and can appear on the left side of a syntax statement

[0104] The syntax statement in K is used to describe syntax and can also be used for some basic function wrapping

[0105] The configuration items in K are used to record the state of semantic execution. The initial state of the configuration item represents the initial state of the program, including the input, and the final state of the configuration item is the result of semantic execution

[0106] The rewrite rules in K are represented by the rule statement, which means reducing a certain syntactic unit to another syntactic unit under certain rules

[0107] K analyzes the input file according to the defined syntax, generates a syntax tree and performs semantics according to the rewrite rules

[0108] Execution

[0109] Verifying security properties in K means converting the security properties into a formal language and proving them during the semantic execution process of K

[0110] Proof

[0111] K syntax illustration

[0112] syntax ClassAccess::="class" ClassName "inherits" CommonName

[0113] |"class" ClassName "inherits" CommonName

[0114] {PermNames}

[0115] |"class" ClassName {PermNames}

[0116] Where

[0117] The double quotes "" indicate that the content inside is a literal

[0118] ClassName starting with an uppercase letter represents a sort in K, that is, a syntactic unit, and can become a node on the syntax tree

[0119] A node

[0120] K configuration item illustration

[0121] configuration <k>$PGM:K< / k>

[0122] The configuration of K is expressed in the form of XML tags. The name of the tag indicates the configuration name, and the content of the tag indicates the value of the configuration item.

[0123] The lowercase k tag is a special tag that indicates the grammatical item to be specified and will be initially used as input for semantic execution.

[0124] K rewrite rule diagram

[0125] rule <k>.Pgm =>....< / k>

[0126] Indicates that rewriting ends when the input is empty

[0127] Semantic execution results

[0128] <generatedtop>

[0129] <k> .< / k>

[0130] < / generatedtop>

[0131] Indicates that all statements have been analyzed.

[0132] The statements in the selinux configuration can be roughly divided into the following parts:

[0133] Objects and Classes

[0134] Type Enforcement

[0135] Access Control

[0136] Users and roles

[0137] Constraint Statements and Conditional Statements

[0138] Multi-level security

[0139] The following is a specific example to illustrate how to write semantics in K to verify security properties.

[0140] SELinux defines several executable operations for each resource in the operating system, which are called permissions. Each resource instance is called an object, and the category of resources is called a class. It also provides a set of permissions called common, which is used to specify multiple permissions at the same time.

[0141] First, in the book "selinux by example", you can find the relevant declaration statement structure about class, permission, and common:

[0142] class<class_name>

[0143] common<common_name> {<perm_set>}

[0144] class <class_name> [inherits <common_name>] [{<perm_set>}]

[0145] They respectively represent a class declaration, a common declaration, and associate permissions with the class.

[0146] Among them, the parts enclosed in <> represent non-terminals, and the rest are literals.

[0147] The syntax of these statements is written in K using the syntax statement as follows:

[0148] syntax ClassName ::= Id

[0149] syntax CommonName ::= Id

[0150] syntax PermName ::= Id

[0151] syntax PermNames ::= List{PermName, ""}

[0152] syntax ClassDecl ::= "class" ClassName

[0153] syntax CommonDecl ::= "common" CommonName {PermNames}

[0154] syntax ClassAccess ::= "class" ClassName "inherits" CommonName

[0155] |"class" ClassName "inherits" CommonName

[0156] {PermNames}

[0157] |"class" ClassName {PermNames}

[0158] In K, a non-terminal is a sort, and terminals or literals are enclosed in double quotes "".

[0159] In K, `List` can be used to represent a structure composed of several identical syntax units arranged, and its effect is equivalent to

[0160] syntax PermNames ::= PermName "" PermNames

[0161] |.PermNames

[0162] For slightly more complex cases, such as the structure of access control statements

[0163] <rule_name><type_set><type_set>:<class_set><perm_set>;

[0164] Its description in "selinux by example" for <type_set> is:

[0165] One or more types or attributes, separated between the source type and the target type

[0166] Multiple types and attributes need to be enclosed in parentheses and separated by spaces, such as

[0167] {bin_tsbin_t}, a type can be excluded from the set by adding a - in front (e.g., {exec_type - sbin_t}), the keyword self is used in the target

[0168] type to indicate the same as the source type, and wildcards * are also allowed in the Neverallow statement

[0169] to indicate taking all, or adding a - outside the curly braces to indicate taking the complement set

[0170] For such grammar units with complex structures, they need to be sorted out layer by layer

[0171] A type_set can consist of one type / attribute

[0172] syntax TypeSet::=TypeName

[0173] syntax TypeSet::=TypeName

[0174] It can also consist of multiple type / attributes, in which case it needs to be enclosed in `{}`

[0175] syntax TypeItems::=List{TypeItem,""}

[0176] syntax TypeSet::="{"TypeItems"}"

[0177] A minus sign - can be added before the type to indicate exclusion

[0178] syntax TypeItem::=TypeName

[0179] | "-" TypeName

[0180] All types can be represented using wildcards

[0181] syntax Wildcard ::= "*"

[0182] syntax TypeSet ::= WildCard

[0183] A tilde can be added before the entire <type_set> to represent the complement set

[0184] syntax TypeSet ::= "~" "{" TypeItems "}"

[0185] Then there is the syntax definition of <type_set> in K

[0186] syntax TypeItem ::= TypeName

[0187] | "-" TypeName

[0188] syntax TypeItems ::= List{TypeItem, ""}

[0189] syntax WildCard ::= "*"

[0190] syntax TypeSet ::= TypeName

[0191] | "{" TypeItems "}"

[0192] | "~" "{" TypeItems "}"

[0193] | WildCard

[0194] The other parts are similar

[0195] When designing configuration items for SELinux in K, the state variables during the runtime of SELinux need to be considered, and data structures need to be designed for the state variables. Some basic data structures, such as Set, Map, and List, have already been provided in K

[0196] Taking the object and class modules as an example, a state variable is needed to record the declared classes, the declared commons, and the relationships between commons and permissions, as well as the relationships between classes and permissions

[0197] The declared class should be a collection, initially an empty collection

[0198] The declared common should be a set, and should initially be an empty set.

[0199] The relationship between common and permission should be a mapping, where each common points to all its associated permissions.

[0200] There should also be a mapping between class and permission, with each class pointing to all its associated

[0201] The configuration items in permission K exist in the form of XML tags. The structure of the configuration items should be similar to:

[0202] <classes>...c1 c2 c3...< / classes>

[0203] <commons>...cm1 cm2 cm3...< / commons>

[0204] <class-perms> ...

[0206] c1 maps to p1 p2 p3...

[0207] c2 maps to p2 p3 p4...

[0208]

[0209] <class-perms>

[0210] cm1|->p1 p2 p3...

[0211] cm2|->p2 p3 p4... ...

[0213]

[0214] Initial state of the configuration item

[0215] <classes>.Set< / classes>

[0216] <commons>.Set< / commons>

[0217] <class-perms>.Map< / class-perms>

[0218] <common-perms>.Map< / common-perms>

[0219] When writing rewrite rules for statements in K, you need to consider the configuration items affected by the statement, changes in the configuration items, and the conditions required by the statement specification.

[0220] Take the very important access control statement in K as an example,

[0221] allow{user_t domain}{bin_tfile_typesbin_t}:file execute; This statement declares an access rule, indicating that the execute operation on file from {user_t domain} to {bin_tfile_typesbin_t} is allowed.

[0222] Configuration items related to this

[0223] <allow>.Set< / allow>

[0224] Represents the access control vector under the action of all allow statements

[0225]

[0226] After parsing the access rule, the status of the configuration item should be similar to

[0227] <allow> ...

[0229] user_tbin_t file|->execute

[0230] domain bin_t file|->execute

[0231] user_tfile_type file|->execute

[0232] domain file_type file|->execute

[0233] user_tsbin_t file|->execute

[0234] domain sbin_t file|->execute ...

[0236] < / allow>

[0237] Therefore, it is necessary to simplify the access control statement first, decompose an access control statement into several simple statements that only declare a single source type, a single target type, and a single class. In fact, special notations such as wildcards, complement sets, and exclusions also need to be considered.

[0238] To distinguish various states of the access control statement during the simplification process, additional syntax can be added

[0239] syntax AccesVector::=RuleNameTypeSetTypeSet:ClassName Perms

[0240] syntax NormalAccessVector::="normal"AccessVector

[0241] syntax FinalAccessVector::="final"AccessVector

[0242] Process wildcards, complements, and exclusions first:

[0243] rule <k>R: Rule Name T1: Type Set T2: Type Set: C: Class Set P: Perms

[0244] => normal R resolveType(T1, AT, TS) resolveType(T2, AT, TS): C P

[0245] ...< / k>

[0246] <attr-types>AT< / attr-types>

[0247] After completing the writing of the rewrite rules, K can already correctly process each statement. Next, the verification of the security model should be considered. Here, the Biba integrity model is taken as an example.

[0248] The Biba integrity model requires classifying the integrity of resources in access control. A subject with low integrity cannot perform write operations on an object with high integrity. For an access control vector

[0249] Type source Type target :ClassPerm

[0250] It is necessary to have

[0251]

[0252] What needs to be done is as follows:

[0253] Classify all types for integrity

[0254] Verify all access control vectors

[0255] Regarding the integrity classification of all types, for simplicity, a trivial classification is adopted here, dividing into two integrity levels: high integrity (trusted) and low integrity (untrusted). The following defines these two integrity levels in K

[0256] First, declare which types are of high integrity (trusted):

[0257] syntax TrustedTypeName::="root_t"

[0258] |"kernel_t"

[0259] syntax TypeName::=TrustedTypeName

[0260] Then, give a method to determine whether a type is of high integrity or low integrity

[0261]

[0262]

[0263] syntax Bool::="canWrite""("TypeName","TypeName")"[function]

[0264] rule canWrite(T1:TypeName,T2:TypeName)

[0265] =>isTrustedType(T1)orBoolnotBoolisTrustedType(T2)

[0266] Then, perform verification at the allow statement

[0267] rule <k>

[0268] final allow T1: TypeName T2: TypeName:

[0269] C: ClassName PS: PermItemSet Set; =>.

[0270] ...< / k>

[0271] requires hasWritePerm(toSet(PS))impliesBoolcanWrite(T1,T2)

[0272] If the final semantic execution ends successfully (kcell in the configuration item is empty), it indicates that the security properties of the target policy are satisfied; otherwise, it indicates that the security policy of the target policy is not satisfied (the current statement in kcell in the configuration item indicates the problem).

[0273] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A formal verification method for selinux security policies based on the KFramework, characterized in that It includes the following steps: S1. Model the selinux security policy language and sort out the BNF grammar; S2. Define the syntax of the selinux security policy language in KFramework. The defined syntax of the selinux security policy language is the syntax statement in K Framework written according to the BNF grammar of the selinux security policy language; S3. Using the defined selinux security policy syntax in KFramework as the carrier, formalize the semantics of the selinux security policy language through the meaning of the statements in the selinux security policy language and write it out in the form of configuration items and rewrite rules in KFramework; S4. Obtain the security model; S5. Obtain the security attributes to be concerned about and the corresponding constraints according to the security model; S6. Write the corresponding specifications in K according to the security attributes and constraints to obtain the specification code in K; S7. Compile the K code for the syntax statement part obtained in S2, the semantic part written in the form of configuration items and rewrite rules obtained in S3, and the specification part obtained in S6 through the compiler kompile provided by K to obtain the semantic execution environment of the selinux security policy language; S8. Obtain the source code of the selinux security policy to be verified; S9. Use the selinux security policy source code as the input of the semantic execution environment obtained in S8 to perform semantic execution and obtain the semantic execution result; S10. Judge whether the security attributes are satisfied according to the semantic execution result to obtain the verification result.

2. The formal verification method of the selinux security policy based on the KFramework according to claim 1, characterized in that In steps S1, S2, and S3, a formal model of selinux is built at the language level, and the syntax and semantics of the selinux policy language are clearly described in the unified language K code.

3. The formal verification method for selinux security policies based on the KFramework according to claim 1, characterized in that The syntax of the selinux policy language described in step S2 and the meaning of the statements in the selinux security policy language described in step S3 are obtained from the documents or manuals provided by the selinux official to ensure their correctness.

4. The formal verification method for selinux security policy based on KFramework according to claim 1 or 2 or 3, characterized in that, The security model in step S5 needs to have a clear formal description, including the state variables in the model and the constraint relationships between the state variables.

5. The formal verification method of the selinux security policy based on the KFramework according to claim 4, characterized in that, The security attributes in step S6 are the constraint relationships of the state variables in the model.

6. The formal verification method for selinux security policy based on KFramework according to claim 5, characterized in that, The specifications in step S6 are additional supplements to the original configuration items and rewrite rules.

7. The formal verification method of the selinux security policy based on the KFramework according to claim 1 or 2 or 3 or 5 or 6, characterized in that, The source code of the selinux security policy to be obtained in step S8 is the single-file source code that has been macro-expanded and conforms to the selinux security policy syntax.

8. The formal verification method of the selinux security policy based on the KFramework according to claim 7, wherein The result of the semantic execution in step S9 is represented by the final state of the configuration item. If there are still unprocessed statements in the configuration item, it means that the statement does not meet the specifications written according to the security attributes in S6.

Images