Section 4.3. Available Object Classes
4.3. Available Object ClassesThis chapter provides an overview of the kernel object classes available in Fedora Core 4 (FC4). Our goal is to describe the object classes and how the system resources are mapped to those object classes. Appendix C provides a reference for all object classes and their associated permissions. The most difficult part of writing good policy is understanding the semantics of the object classes and permissions and the implications of those semantics in the context of an application policy on a particular system. An FC4 system has more than 40 kernel object classes representing all the resources provided by the kernel. The number of object classes illustrates a basic philosophy in SELinux to represent the kernel resources as completely and accurately as possible. The richness and complexity of Linux means that this accurate representation is necessarily rich and complex itself. This complexity may seem daunting, but it is necessary to give SELinux the flexibility to fully address the security challenges facing Linux. Tools and technology are emerging that use the richness of SELinux to provide sophisticated security without the user needing to be aware of the underlying complexity. To ease understanding, we divide the kernel object classes into four categories: file-related, network-related, System V IPC, and miscellaneous. 4.3.1. File-Related Object ClassesThe first category of object classes are those related to files and other resources stored in filesystems. These are often the most familiar object classes to most users. Included in this category are all the object classes that can be associated with persistent, on-disk filesystems and with in-memory filesystems, such as proc or sysfs. In UNIX-like systems, an underlying concept is that "everything is a file." This is in many ways true, but it obscures the fact that not all "files" are the same. In reality, a modern UNIX-like system such as Linux has special files for devices, and IPC, in addition to standard files used for the storage of data. SELinux accurately represents this more detailed view of the kernel. Table 4-1 summarizes the file-related object classes.
The object classes file and dir represent ordinary files and directories, respectively. Ordinary files are those files that store data; they are the most familar objects on most systems. Directories, which are a special file in Linux, are unique because they can contain other objects. The lnk_file object class represents symbolic links. It is important in many situations to distinguish between regular files and symbolic links to prevent common attacks. Malicious processes and users can create symbolic links that cause a process to access or modify files other than those intended. The separate lnk_file object class allows policies to be written that prevent these types of attacks. The object classes fifo_file and sock_file represent special files used for IPC. The fifo_file object class represents fifo files, also called named pipes. The sock_file object class controls the ability to create, access, and so on the file-related object associated with a UNIX domain socket. We discuss the UNIX domain socket object classes and their relationships to socket files in the next section. In Linux, devices are accessed through special files that are commonly found in the /dev/ directory. These files represent, through major and minor device numbers, block and character devices. Character devices are those devices that programs read or write data to or from as a stream of bytes. Block devices are those devices that require data to be passed in larger blocks. The chr_file and blk_file object classes represent character and block devices, respectively. The final two object classes in this category, filesystems and file descriptors, are not typically considered objects in Linux. The filesystem object class represents a mounted filesystem. This object class controls global operations such as mounting or querying quotas. For example, using the filesystem object class, we can allow only mounting of filesystems that support the storage of security contexts. All filesystems of a particular type (for example, ext3) get a default label defined in the policy with the fs_use statement, which is described in Chapter 10, "Object Labeling." That default type may be overridden when the partition is mounted with the context mount option, also described in Chapter 10. File descriptors are handles, representing opened file-related objects, stored within processes. Although distinct from the file-related objects they represent in kernel data structures, it is common to think of file descriptors as the underlying file-related object. Indeed, standard Linux access control does not provide access control over file descriptors separately from that of the underlying object. This strategy ignores the fact that file descriptors are distinct resources that can be passed between processes, most commonly when a child inherits the file descriptors from its parent. This inheritance is not always desirable, and admonishments to reduce file descriptor inheritance appear in many Linux programming guides, particularly for daemons. To address this and other issues, we have the fd object class, which represents file descriptors in SELinux. Using this object class it is possible to prevent the usage of file descriptors passed or inherited between processes. It is important to note, however, that the permission to use a file descriptor is not sufficient to access the underlying file-related object; the process must also have the associated permission on the underlying object. 4.3.2. Network-Related Object ClassesThe network-related object classes represent network resource such as network interfaces, various types of sockets, and hosts. The current object classes are sufficient to allow comprehensive control over networking on a single system. Further enhancements in this area, such as labeled network packets, are likely in the future. [2] Table 4-2 summarizes the network- and socket-related object classes.
The node, netif, packet_socket, rawip_socket, tcp_socket, udp_socket, and socket object classes control typical access to the network. The netif object class represents network interfaces. Each named network interface (for example, eth0, eth1, and so on) is represented by an instance of the netif object class. Remote hosts on the network, identified by IP address or range, are represented by the node object classes. Using the node object class, we can limit the hosts (via IP address) to which a process may interact over the network. The various socket object classes listed previously represent the kinds of socket by protocol. Successfully sending or receiving network data requires permissions on all the relevant netif, node, and socket object class instances. The standard networking sockets are divided by protocol (as determined on creation by the socket(2) system call). The different socket object classes allow us to limit the type of packets an application can send or receive. This is particularly helpful in limiting the capability of applications to send raw packets. The object classes tcp_socket and udp_socket represent sockets for TCP and UDP, respectively. The rawip_socket object class represents sockets for sending raw IP packets and the packet_socket object class represents sockets for sending any other type of raw packet. All other sockets are represented by the socket object class. Communication using IP Security (IPsec) has additional resources represented by the object classes association and key_socket. An IPsec security association is a connection that affords security services to the traffic that it carries. The association object class repesents IPsec associations. IPsec requires the management of keys through a key management (PF_KEY) socket, which is represented by the key_socket object class. Local communications on Linux boxes can be accomplished using UNIX domain sockets (PF_UNIX). These sockets are commonly used for local IPCs. Connection-oriented sockets, also called stream sockets, are represented by the unix_stream_socket object class; datagram sockets are represented by the unix_dgram_socket object class. UNIX domain sockets can be associated with a special file in a filesystem to allow other applications to easily connect to the socket. This file is represented by the sock_file object class, a file-related object class described earlier. The final group of sockets in SELinux are the Netlink sockets. These sockets were originally developed to provide a standard means of configuring networking in Linux. [3]. They are now used to communicate a variety of information between kernel and userspaces. There are several object classes representing Netlink sockets based on protocol type, and the generic netlink_socket for any remaining protocols without a specific object class.
4.3.3. System V IPC Object ClassesThe IPC-related object classes represent System V IPC resources (see Table 4-3). The msgq and msg object classes represent message queues and the messages in a message queue. The sem object class represents semaphores. The shm object class represents shared memory segments. Note that access to global system information about all System V IPC resources is controlled by a permission on the system class.
4.3.4. Miscellaneous Object ClassesTable 4-4 lists a number of remaining object classes that do not easily fit into one of the other categories. The capability object class represents process capabilities in the standard Linux access control model. This object class allows SELinux to control the capabilities granted to "root" processes. Examples of these capabilities include the ability to override the discretionary access controls (permissions modes) and send raw network packets. This object class and its permissions allow control over whether a process may use a capability it already has been granted by standard Linux. The remaining two object classes, security and system, represent access to special resources of the SELinux security server and the system, respectively. They are unique in that there is only ever one instance of each of these object classes, reflecting that there is ever only one security server and system.
|
EAN: 2147483647
Pages: 154