4.2 Defining the object class in the SELinux policy

A policy must contain declarations of all object classes and permissions supported by the SELinux kernel and other object managers. Generally speaking, as a strategy writer, we don't have to worry about creating new object classes. However, we need to understand the defined object class to write a more efficient SELinux strategy. It is useful to understand the object class and the permission declaration syntax, because it allows us to understand the object classes and permissions that are supported by the version of the policy we are using.

Add a new object class and permissions

Adding a new object class and modifying permissions on an existing object class is a very complex task, usually only when the system code itself is modified. Unlike other aspects of the SELinux policy language, object classes and permissions are tightly bound to the Linux details implementation, especially the kernel. In fact, object classes and permissions are designed to represent the resources that are implemented by the system as precisely as possible. For this reason, it is very meaningful to change the object class and permissions to match the corresponding system when the system changes.

An example of a type change is authorizing a change in the object class, and the permission is the addition of the IPC to the new form of the kernel. In this instance, a completely new resource class is added, like a new or extended system call, and a new object category may be required to represent the semantics of this resource.

Adding or changing the object class or semantics requires more than just modifying the policy, but also modifying the system code, which enforces access control based on the new object class or permissions. Simply adding object classes or permissions to a policy without modifying the code has no other effect than wasting kernel memory.

Basically, you should never change the object class and permission definitions for the book's target audience (SELinux policy writers and administrators).

4.2.1 Declaration Object Class

Object classes are declared using class declaration statements. A class declaration statement simply declares the name of an object class, and nothing else. For example, we define an object class for a category with the following description.

class dir

A class declaration consists of the keyword "class" and the following class name. Note: Class declarations do not end with semicolons.
The object class name has a separate namespace. It is possible to have the same name for the object class, permission, type (identifier), but that is a bad strategy writing method.
Class definition syntax

The class definition allows you to declare the object class name. The following is the full syntax of the class declaration:

class class_name

The identifier of the Class_name object class. This identifier can be any length and can contain ASCII characters or numbers

The class definition is valid only in the overall policy and the basic loadable module. He is not valid in conditional statements and non-basic loadable modules.

4.2.2 Declaration and associated object class permissions

There are two ways of declaring permissions. The first is called public permission, and allows us to create a permission that is associated with the object class as a group. Public permissions are useful when the object class shares a series of access rights. The second method, called Class-specific permissions, allows us to declare specific permissions for a class individually. As we can see, there are some object classes that have only specific permissions, some have only public permissions, and some of these two permissions.

4.2.2.1 Public Permissions

The public permission statement allows us to declare the permissions of some columns to be associated with two or more object classes to form a group. The full syntax of the public permission statement will be shown later. For example, the Unix "Everything is file" Creed means that many file-related object classes have public permissions. Here's how a file-related permission is declared:

file{    ioctl    read   write   create   getattr   setattr   lock    relabelfrom   relabelto   append     unlike   link   rename   execute   swapom   quotaon   mounton}

This statement declares a public permission set called a file, and it defines some relevant permissions. A public permission statement itself is ineffective. He will be useful when we associate these permissions with the object class.

Just like object classes (objects), public permission names are declared in their own namespaces. When we are not careful, we may confuse us. For example, as we explained in the previous example, we have an object class and a public permission name for the file. Although the names are the same, they are actually two different components of the strategy.

Public Permission statement syntax

A public permission statement allows you to declare a public permission name that has a set of permissions that can be associated with the object class as a group. Public permissions can be associated with multiple object classes. The following is the full syntax for a public permission statement.

commom commom_name {perm_set}

Common_name The identifier for the public permission. The object class can be any length and can contain ASCII characters, numbers and dashes (-), and a little (.).

Perm_set one or more permission identifiers in a space-separated list. Identifiers can be of any length and can contain ASCII characters, numbers, dashes, and dots

A public permission set uses an Access vector statement to associate to the object class.

Public permission statements are valid only in the overall policy and the basic loadable module. They are not valid in conditional statements and non-basic loadable modules.

4.2.2.2 permissions and Object classes associated

We use an Access vector statement to associate permissions with the object class. We use Access vector statements to correlate public and class specific permissions. For example, the following statement associates the object class dir with a single class-specific permission.

class dir{search}

As this example shows, an access vector statement looks much like a class definition statement. A class definition statement and an Access vector statement start with the same keyword, but they are different. The access vector statement must provide a previously defined class name and provide one or more permissions. In this example, we define a single, class-specific permission, and note that the statement does not have a good ending.

The previous access vector statement causes the Dir object class to have a class-specific permission: Search. In general, in an object class you will see a lot of permissions, just like the following statement.

class dir{search add_name remove_name}

This example associates three class-specific permissions with the object class dir. We can also associate public permissions with object classes by using the optional key child "inherits" in an access vector statement. For example, the Dir object class is one of many object classes with similar file types, and shares public permissions with other file-similar object classes. The following access vector statement is a complete statement that associates die and public permission files together, as shown earlier, and some class-specific permissions make them different from other directories.

class dir inherits file{    ?add_name    ?remove_name    ?reparent    ?search    ?rmdir}

As this example illustrates, we associate all public permissions with Dir by using the keyword "inherits" plus the public permission set (file) that was declared earlier. The result of this statement is that the object class dir valid permissions are those previously defined public permission file, and there are five specific permissions of Dir.

It is possible for an object class to have only public permission. For example, an access vector statement for an object class link file (lnk_file):

class lnk_file inherits file

This statement causes the class Lnk_file to have only the permissions defined in the public permission file, and nothing else.

Similarly, it is possible for an object class to have only class-specific permissions (that is, there is no public permission). For example, an access vector statement representing the object Class (FD) of a file descriptor has a single class-specific permission that allows the use of file descriptors.

class fd {use}

Access Vector statement syntax

The Access Vector Statement associates the permission with the object class previously declared. The following is the complete syntax for an access vector statement:

class class_name [inherits common] [{perm_set}]//class_name     ?之前声明的客体类名称//commom     ?    ?之前声明的公共权限集合名称//perm_set      ?   在一个分离空间列表中的一个或多个权限标识符．        标识符可以是任意长度，可以包含ASCII字符，数字还有点在最小情况下，common和perm_set至少要提供一个，或者是两个都提供．访问向量语句的最后结果就是这两个方面的权限的集合．访问向量语句仅仅在整体策略或者是基本可加载模块中是有效的，但是在条件语句和非基本可加载模块中是无效的．

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

4.2 Defining the object class in the SELinux policy