4.2. Defining Object Classes in SELinux PolicyA policy must include declarations for all object classes and permissions supported by the SELinux kernel and other object managers. In general, we, as policy writers, are not concerned with creating new objects classes; however, we need to understand the object classes that are defined to write effective SELinux policies. It is useful to understand the object class and permission declaration syntax because it allows us to understand the supported object classes and permissions in the policy version we are using.
4.2.1. Declaring Object ClassesObject classes are declared using the class declaration statement. The class declaration statement simply declares an object class name and nothing else. For example, we declare an object class for directories (named dir) with the following statement: class dir The class declaration statement consists of the keyword class followed by the class name. Notice that the class declaration statement does not end in a semicolon like many other policy statements. You can see the full syntax for the class statement in the sidebar on page 63. Object class names have a separate namespace. It is possible, but generally poor policy writing practice, to have object classes, permissions, types, and so on all have the same name.
4.2.2. Declaring and Associating Object Class PermissionsThere are two methods of declaring permissions. The first is called common permissions and allows us to create permissions that we associate with an object class as a group. Common permissions are useful when similar object classes (for example, files and symbolic links) share a set of access permissions. The second method is called class-specific permissions and allows us to declare permissions specific to that object class alone. As you will see, some object classes have only class-specific permissions, some have only common permissions, and some have both. 4.2.2.1. Common PermissionsThe common permission statement allows the creation of sets of permissions that we associate as a group with two or more object classes. The full syntax of the common permission statement is shown in the sidebar on page 64. For example, the UNIX philosophy of "everything is a file" means that many file-related object classes have a common set of permissions. A common permission statement to declare these file-related permissions in SELinux is as follows: common file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton } This statement declares a common permission set called file and defines it as a set of permissions called ioctl, read, write, create, and so on. A common permission statement by itself has no effect; it is only when we associate a set of common permissions with an object class that they are useful. As with object classes, common permission names are declared in their own namespace. This can lead to some confusion if we are not careful. For example, as illustrated in the preceding examples, we have both an object class and a common permission named file. Although the names are the same, they are in fact two distinct and very different components of the policy.
4.2.2.2. Associating Permissions with Object ClassesWe associate permissions with an object class using the access vector statement. The full syntax for the access vector statement is shown in the sidebar on page 66. We use the access vector statement to associate common and class-specific permissions. For example, the following statement associates a single class-specific permission with the object class dir: class dir { search } As this example shows, the access vector statement looks similar to the class declaration statement (a similarity attributable to the reuse of the keyword class). The class declaration and access vector statements are distinct despite beginning with the same keyword. The access vector statement must provide a previously declared object class name (dir) and then provide one or more permissions. In this partial example, we define a single, class-specific permission (search). Notice that this statement also does not end in a semicolon. The previous access vector statement would result in the dir object class having one class-specific permission: search. In general, you would see multiple permissions for an object class, as follows: class dir { search add_name remove_name } This example associates three class-specific permissions with the object class dir. We can also associate common permissions using the optional inherits keyword in the access vector statement. For example, the dir object class is one of several object classes that are "file-like" and share common permissions with other file-like classes. The following access vector statement is a complete access vector statement for dir associating the common permission file, shown previously, along with several class-specific permissions unique to directories: class dir inherits file { add_name remove_name reparent search rmdir } As this example illustrates, we use the keyword inherits followed by the name of a previously declared common permission set (file) to associate all the common file permissions with dir. The result of this statement is that the valid permissions for the object class dir are all those defined earlier for the common permission file and the five permissions specific to dir. It is possible to have an object class that has only common permissions. For example, the access vector statement for the object class for symbolic link files (lnk_file) is this: class lnk_file inherits file This statement results in the class lnk_file having only those permissions defined in the common permission file and no others. Likewise, it is possible to have object classes with only class-specific permissions (that is, no common permissions). For example, the access vector statement for the object class representing file descriptors (fd) has a single class-specific permission allowing use of a file descriptor: class fd { use }
|