In this lesson, you will learn how to bridge the gap between abstract SELinux security labels and the low-level actions allowed on system resources.
Defining the Object Class
In SELinux, a "Security Context" tells the kernel what a file or process is, but the "Object Class" tells the kernel what kind of resource it is dealing with. SELinux classifies every system resource into specific object classes, such as file, dir (directory), socket, process, or shm (shared memory).
Each class is hardcoded into the kernel's security server. When a process attempts an action, the kernel looks at the source security context and the target security context, then checks the specific object class to see if the requested operation is permitted.
Mapping Permissions
Permissions in SELinux are not global; they are scoped to the object class. For example, a file object class supports permissions like read, write, getattr, and execute. However, a socket object class uses different permissions, such as bind, connect, or listen.
You define these interactions within your policy modules using allow rules. Consider this example for a hypothetical custom application domain myapp_t:
# Allow our app to read and write to its specific data files
allow myapp_t myapp_data_t:file { read write getattr open };
# Allow our app to communicate via TCP sockets
allow myapp_t myapp_t:tcp_socket { create connect read write };
In this code block, we are explicitly mapping the myapp_t domain to the file class and the tcp_socket class. If you tried to use connect on a file object, the kernel would reject it immediately because that permission does not exist for that object class.
By strictly defining these permissions, you ensure that even if an attacker compromises a service, they cannot use its files as sockets or manipulate memory regions in ways the developer never intended. You are essentially creating a custom "grammar" for how each part of your application is allowed to interact with the Linux kernel’s infrastructure.
Key Takeaway: Object classes enforce granular security by restricting specific operations to the resources where those actions are logically meaningful.