Flylib.com

Books Software

 
 
 

Part II: SELinux Policy Language


Part II: SELinux Policy Language

 

Chapter 4 Object Classes and Permissions page 59

 

Chapter 5 Type Enforcement page 89

 

Chapter 6 Roles and Users page 129

 

Chapter 7 Constraints page 149

 

Chapter 8 Multilevel Security page 163

 

Chapter 9 Conditional Policies page 183

 

Chapter 10 Object Labeling page 205



Chapter 4. Object Classes and Permissions

In this chapter

  • 4.1 Purpose of Object Classes in SELinux

  • 4.2 Defining Object Classes in SELinux Policy

  • 4.3 Available Object Classes

  • 4.4 Object Class Permission Examples

  • 4.5 Exploring Object Classes with Apol

  • 4.6 Summary

  • Exercises

page 60

page 61

page 67

page 73

page 84

page 86

page 87


This chapter covers object classes and permissions defined in SELinux. We discuss the policy language statements that define object classes and permissions the kernel supports and provide an overview of the kernel object classes standard in a SELinux system. Appendix C, "Object Classes and Permissions," includes a detailed listing of each standard SELinux object class and its associated permissions.



4.1. Purpose of Object Classes in SELinux

Object classes and their associated permissions are the basis for access control in SELinux. Object classes represent categories of resources such as files and sockets, and permissions represent accesses to those resources such as reading or sending. Understanding object classes and permissions is a difficult aspect of SELinux because it requires both SELinux and Linux knowledge.

An object class represents all resources of a certain kind (for example, files or sockets). An instance of an object class (for example, a specific file or socket) is simply called an object. Often the terms object class and object are used interchangeably, but it is important to understand the difference. Object class refers to the entire category of resources (files); object refers to a specific instance of the object class ( /etc/passwd ).

As discussed in Chapter 2, "Concepts," access to objects is expressed in the policy through permissions to object classes that have a specified type(s). To illustrate , let's consider an allow rule from Chapter 2:

allow user_t bin_t : file {read execute getattr};


In this rule, processes with the type user_t (that is, the source or subject) are allowed to read, execute, and get attributes for all objects of class file that have the target type ( bin_t ) in their security context. The object class file specifies the category of resource, and bin_t specifies which instances of that category of resources to which this rule applies (that is, those file objects that have the type bin_t ). It does not apply to objects that have bin_t type that are not of file class nor to file objects that do not have bin_t as their type.

The permissions in this rule read , execute , and getattr define the access allowed to those objects by subjects (implicitly process objects) that have the type user_t . Each of these permissions, which must be valid for the file object class, represent some form of access to the objects. (For example, the read permission is required to use the open (2) system call to open a file for reading, use the read(2) system call on an opened file, and so on.) The set of permissions defined for an object class (also called an access vector ) represents all the possible access that can be allowed to the resources represented by that object class.

The set of object classes available depends on the version of SELinux and its Linux kernel. Over time, new and different object classes have evolved to address new and changed features of the kernel. For example, newer versions of the Linux kernel have introduced a new Netlink-specific socket for controlling the audit framework. [1] . For those kernels that support the Netlink socket, there is an SELinux object class with appropriate permissions defined.

[1] Information about and source code for the Linux audit framework and tools is available at http://people.redhat.com/sgrubb/audit/