Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

2.5. Object Classes and Permissions

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
}

 
 
  Published under the terms of the GNU General Public License Design by Interspire