3.3 SELinux Policy language

3.3.1 Local SELinux Policy language compiler

The most basic way to build a policy file for the kernel is to compile it from the source policy file using the CheckPolicy program. This source program, which is built in many steps, is named "Policy.conf". CheckPolicy checks the syntax and semantics of the source policy file and writes the result in a certain form (taken by a binary policy file) to a file that can be read by the Kernel Policy loader (load_policy). The language syntax supported by CheckPolicy is the native language supported by SELinux. You can consider CheckPolicy language as language similar to assembly language. High-level languages and other, more abstract ways to create policies are also being developed, which will be discussed later. For now, our focus is on the local policy language and the building of a policy for kernel enforcement.
?
Let's take a look at the basic components of the policy source file described below.

The first part of the policy source file defines the object class to the secure server. This section also defines the permissions of other object classes. For the kernel, these classes are directly related to the kernel source files. As a general rule, as a kernel policy writer, you should never modify object classes and permission definitions as much as possible. The specified object classes and their associated permissions are discussed in later chapters.

The next section contains a description of TE, which is the largest part of the current position SELinux strategy. This part of the strategy writer will take a lot of time to write. He contains all the marking (type) declarations and TE rules (including all allow,type_transition and other TE rules). The fifth chapter discusses the type and core of te rules in detail. The "Type enforcement" section typically contains thousands of type declarations and tens of thousands of te rules. This section will also contain some rules and statements about roles and users. Users and roles that support the concept of TE will be discussed in chapter 6th.

The next section of the policy source file contains some restrictions. Constraints provide a means to further limit the TE policies that are allowed beyond the TE rules. For example, the MLS strategy is implemented as a series of constraints. The limitations and MLS are discussed in chapters seventh and eighth.

The last part of the policy file contains the label designation (labeling specification). All objects are bound to the security context. This section tells SELinux how to treat the file system, that is, how to treat tagged files that were created during file system operation. A separate related mechanism, called a file context file, is used to initialize files, directories, and other security context tags on the object of the persistent file system. These and other topics related to topic labeling are discussed in chapter tenth.

Check the policy.conf file
As the binary policy file is CheckPolicy created, you can use the Tresys Apol tool to view, find, and analyze the contents of the policy.conf file. The policy.conf file is more abstract than the binary file format, which makes it easier to analyze and debug your strategy. At the same time, the policy.conf file is the most similar in form to the source file, so this file is also the best form for tracking bugs in the source file. In any case, both are very important and should reflect the same security policy.

3.3.2 The source policy module in the overall strategy

In today's selinux strategy a common type is to have a holistic strategy. This strategy was checkpolicy built into an egg a binary policy file, which is loaded directly into the kernel. Because SELinux policies are often very large and complex, such as software, they are built into small units called modules. There are many ways to build a policy module. The most primitive and most commonly used method is called the source module, which supports the development of the overall strategy. The source module combines scripts, M4 macros and makefile files with text files to create a more advanced language. The policy module is linked to a single large source file (that is, policy.conf), which is then compiled by checkpolicy into a binary file that can be read by the kernel.

3.3.3 loadable Policy Module

A new method of creating a module policy is called a loadable module that uses CheckPolicy's most recent extension and a module compiler (Checkmodule) to build loadable policy modules that are compiled separately. Loadable modules are also the basis of a policy server. In the case of a module, the technology is no longer built into a monolithic binary strategy, but rather, the core subset of a strategy is built, called the Basic module. You create the base module more like you create the overall strategy. With loadable modules, you can organize basic modules that contain only the rules related to the core operating system. Other parts of the policy are created with detached loadable modules. When you install their related packages, you can talk about all the other policy rules in a modular way.

The Loadable module causes a change in the policy syntax, which is designed to separate the policy into an assignable policy module. These changes are not the same as the base and fee base modules. The base module uses the same policy language as the overall strategy language, with just a little bit of attachment. Non-basic modules (that is, loadable modules) use a subset of the standard policy language with many additional language features. A subset of these policy languages contains a number of te, rules, and user descriptions. Additional language features are used to manage the modules since. The language changes in the Loadable module are explained later.

Fedora Core5 (FC5) has adopted the basic features of loadable modules for future releases. In this book, we discuss only the overall strategy approach and the features of the latest loadable modules in the sidebar.

3.3.4 Building and installing the overall strategy

Once you have finished reading the rest of the book, you will likely experiment with the SELinux strategy writing. You will need to compile your changes into the overall policy file and test your changes by loading the new policy into the kernel, and test the results with the kernel's access control forces. Before you make these attempts, we must first introduce a basic approach to building and installing kernel security policies.

Skills:

Be sure to keep in mind that if you are installing your policy, the kernel will immediately start forcing access based on the rules in the policy. When you are studying SELinux and testing the language, you may cause the program to crash due to lack of access. We recommend that you use the permissive mode (Setenforce 0) When testing your own strategy, until you are familiar with the policy language and its consequences after changing the pattern. Of course, you can also always run the system in enforcing mode (Setenforce 1).

The following example is a typical way to build a strategy

Starting from the left side of this picture, you have a policy file that is broken down into many source modules. In the following book, we will discuss a variety of ways to organize these modules. For now, just know that these files are through script, macro processor etc to merge these files into a single policy file policy.conf on the line, the file is a full, syntactically correct description of the SELinux source policy. Then you use CheckPolicy to compile the source policy into the appropriate binary policy file for the kernel (assuming there are no errors). The Load_policy program is then called to load the binary policy file into the kernel, and the kernel enforces access control based on policy rules.

In this part of the book, you may find this process very confusing, especially as we discuss the strategy building approach rather than the source module to build the strategy. Don't panic, we just want you to have a holistic understanding of the process. The policy source directory typically has a makefile file that will automatically build this process for you. In the policy, we use the policy in Part 2, if the installation succeeds in/ec/selinux/strict/src/policy/, here are some interesting make targets.

Policy: Makes policy.conf and policy. [ver] local test compilation and check errors
Install:? Doing everything can be everything that a policy installs into the system, such as loading into the kernel and policy configuration files during the kernel boot phase, etc.

Load: Do something that allows binary policy files to be loaded into the kernel, such as activating access control policies and installing File_context files.

Therefore, you can install the strategy (in addition to the final installation and loading strategy) by installing the methods shown above.

Copyright NOTICE: Hello, reprint please leave my blog address, thank you

3.3 SELinux Policy language