SELinux defines a number of classes for objects, making it easier to group
certain permissions by specific classes. Here are some examples:
File related classes include
filesystem for file systems,
file for files, and
dir for directories. Each class has
it's own associated set of permissions. The
filesystem class can mount, unmount,
get attributes, set quotas, relabel, and so forth. The
file class gains the common file
permissions such as read, write, get and set attributes, lock,
relabel, link, rename, append, etc.
Network related classes include
tcp_socket for TCP sockets,
netif for network interfaces, and
node for network nodes. The
netif class, for example, can send
and receive on TCP, UDP and raw sockets
(tcp_recv,
tcp_send,
udp_send,
udp_recv,
rawip_recv, and
rawip_send.)
The object classes have matching declarations in the kernel, meaning that
it is not trivial to add or change object class details. The same thing
is true for permissions. Development work is ongoing to make it possible
to register and unregister classes and permissions dynamically.
Permissions are the actions that a subject can
take on an object, if the policy allows it. These permissions are the
access requests that SELinux actively allows or denies.
There are several common sets of permissions defined in the targeted
policy, in $SELINUX_SRC/flask/access_vectors. These allow
the actual classes to inherit the sets, instead of rewriting the same
permissions across multiple classes:
# Define a common prefix for file access vectors.
#
common file
{
ioctl
read
write
create
getattr
setattr
lock
relabelfrom
relabelto
append
unlink
link
rename
execute
swapon
quotaon
mounton
}
# Define a common prefix for socket access vectors.
#
common socket
{
# inherited from file
ioctl
read
write
create
getattr
setattr
lock
relabelfrom
relabelto
append
# socket-specific
bind
connect
listen
accept
getopt
setopt
shutdown
recvfrom
sendto
recv_msg
send_msg
name_bind
}
# Define a common prefix for ipc access vectors.
#
common ipc
{
create
destroy
getattr
setattr
read
write
associate
unix_read
unix_write
}
Following the common sets are all the access vector definitions. The
definition is structured this way: class
<class_name> [ inherits
<common_name> ] {
<permission_name> ... }. A
good example is the dir class, which
inherits the permissions from the file
class, and has additional permissions on top:
class dir
inherits file
{
add_name
remove_name
reparent
search
rmdir
}
Another example is the class for
tcp_socket, which inherits the
socket set plus having its own set of
additional permissions:
class tcp_socket
inherits socket
{
connectto
newconn
acceptfrom
node_bind
}