A userspace Process Classifier based on SELinux Security_context(PCSS)

  |    home     |      Scope    |     Important Links     |     Contact      |

CPUSETs are lightweight objects in the linux kernel that enable users to partition their resources by creating resource groups. A virtualization layer has been added so it becomes possible to split a machine in terms of CPUs. The main motivation of this patch is to give the linux kernel full administration capabilities concerning CPUs. To make it possible, different CPUSETS are defined with different (or overlapping) group of resource and each process is classfied to one of these CPUSET. All processes belonging to one CPUSET class, will share all the resources available with that CPUSET among each other. This way, we can create different CPUSET's and classify the processes in them so that critical processes will easily get needed resources.


In order to classify the processes in these CPUSET's, one need to get their PID's, and add it to perticular file in the directory indicating the required CPUSET. Here, classification is not possible until process is actually created. And if process restarts, then it should be re-classified, as its PID will change. Simillarly, after every reboot classification has to be re-done.
So, one need to do lot of, repetative and mannual classification of processes if one wants to use CPUSET effectively.


If we can classify processes without using PID, and if classification remains same even after process restarts or machine restarts then we can automate most of the work.
Also classification should be very flexible. So that it can cover all posibilities and scenarios.

  General overview

	         KERNEL SPACE           |             USER SPACE
                        	        |       ---------------------              ******************
	          Process Events  1. NETLINK   |    Userspace Daemon |---------->* Configuration file *   
      	          connector       -----------> |     jobs manager    |<----------*                    *
					|        --------------------		   ******************
        	                        |        2.|   ^      4.|         
        	                        |          |   |        |                	   
                	                |          |   |     	|              		   	
                  *********             |          |   |     	|             
	         * SELinux *  <--------------------    |	|            
                  *********            	|              |     	|            
                   3.|    		|    	       |        |
                     |                  |              |        |
		     ----------------------------------         |
                             	        |                       |
                                        |                       |          
		 *********		|			|	  
	        * CPUSETfs*   <----------------------------------	   
                 *********              |   				   	
		  5.|		        |				   
                    |                   |                                  
		    |			|                                  
                    V                   |                                  
                 ********************   |                             
     	        * CPUSETs (Classified)* |
                 ********************   |               

We are using Connector (A Linux Kernel feature) which reports process events to userspace. It uses netlink mechanism and your kernel should be build with it.
This kernel feature will report process events like fork and exec. Whenever these events are reported, one userspace program named "userspace_listener.c" will receive these events. Now we can find out the security context of the process related to the event from SELinux kernel module. We are using system call "getpidcon" to get the security context from kernel.
This security context is then matched with the rules given by users for the classification. These rules are very simple and are kept seperately in one text file in following format.
If security context of current process matches to any security context provided by user rules, then current process can be classified into that class.
assification is then enforced by requesting kernel to change the cpuset of current process to new cpuset. This is done by means of system calls.