Section 4.2. Defining Object Classes in SELinux Policy


4.2. Defining Object Classes in SELinux Policy

A 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.

Adding New Object Classes and Permissions

Adding new object classes and changing the permissions on existing object classes are complex tasks that should normally be undertaken only when changing the actual system code itself. Unlike other aspects of the SELinux policy language, object classes and permissions are closely tied to the implementation details of Linux, particularly the kernel. In fact, object classes and permissions are designed to represent as accurately as possible the resources implemented by the system. For this reason, it makes sense to change the object classes or permissions that match a corresponding change in the system.

An example of the type of change that would warrant a change in the object classes and permissions is the addition of a new form of interprocess communication (IPC) to the kernel. In this case, an entirely new category of resource is being added, likely with new or expanded system calls, and a new object class would likely be required to accurately represent the semantics of this resource.

Adding or changing object classes or permissions requires changes both to the policy and to the system code that will enforce access control based on the new object classes or permissions. Simply adding an object class or permission to the policy without changing the code will likely have no effect other than wasting kernel memory.

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


4.2.1. Declaring Object Classes

Object 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.

Class Declaration Statement Syntax

The class declaration statement allows you to declare object class names. The full syntax of the class declaration statement is as follows:

class class_name

class_name

An identifier for the object class. The identifier can be any length and can contain ASCII letters or numbers.


Class declarations are valid only in monolithic policies and base loadable modules. They are not valid in conditional statements and non-base loadable modules.


4.2.2. Declaring and Associating Object Class Permissions

There 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 Permissions

The 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.

Common Permission Statement Syntax

The common permission statement allows you to declare a common permission name that has a set of permissions that can be associated with an object class as a group. Common permissions can be associated with multiple object classes. The full syntax for the common permission statement is as follows:

common common_name { perm_set }

common_name

An identifier for the common permissions. The identifier can be any length and can contain ASCII letters, numbers, a dash (-), or a period (.).

perm_set

One or more permission identifiers in a space-separated list. The identifiers can be any length and contain ASCII letters, numbers, a dash (-), or a period (.).


A common permission set is associated with an object class using the access vector statement.

Common permission statements are valid only in monolithic policies and base loadable modules. They are not valid in conditional statements and non-base loadable modules.


4.2.2.2. Associating Permissions with Object Classes

We 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 }


Access Vector Statement Syntax

The access vector statement associates permissions with a previously declared object class. The full syntax for the access vector statement is as follows:

class class_name [ inherits common ] [{ perm_set } ]

class_name

A previously declared object class name.

common

A previously declared common permission set name.

perm_set

One or more permission identifiers in a space-separated list. The identifiers can be any length and contain ASCII letters, numbers, or a period (.).


At a minimum, either one common or a perm_set must be specified, but both can be provided. The resulting permissions for the object class are the union of the common permissions and the perm_set.

Access vector statements are valid only in monolithic policies and base loadable modules. They are not valid in conditional statements and non-base loadable modules.





SELinux by Example(c) Using Security Enhanced Linux
SELinux by Example: Using Security Enhanced Linux
ISBN: 0131963694
EAN: 2147483647
Year: 2007
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net