Policy Originator Project
=========================
 
Purpose
-------
 
When working with a SELinux-enabled system, additional privileges are 
constantly being checked to see if a specific action is allowed. These 
actions are most often shown as allow rules, like so:
 
allow sendmail_t kmail_t:process sigchld;
 
These rules are not written and maintained in their raw format. Instead, a 
higher-level, M4-based language construct is used in which interfaces are 
defined with more human readable names, like so:
 
mta_send_mail(kmail_t)
 
This interface then translates the call into either more interfaces, or 
raw SELinux policy rules:
 
interface(`mta_send_mail',`
        gen_require(`
                attribute mta_user_agent;
                type system_mail_t;
                attribute mta_exec_type;
        ')
 
        allow $1 mta_exec_type:lnk_file read_lnk_file_perms;
        corecmd_read_bin_symlinks($1)
        domtrans_pattern($1, mta_exec_type, system_mail_t)
 
        allow mta_user_agent $1:fd use;
        allow mta_user_agent $1:process sigchld;
        allow mta_user_agent $1:fifo_file rw_fifo_file_perms;
 
        dontaudit mta_user_agent $1:unix_stream_socket rw_socket_perms;
')
 
Most policy development currently focuses on adding additional privileges, 
and not removing existing privileges. However, it is important that we can 
query where a privilege comes from, not only to query the existing 
policies and verify if the rules are still needed, but also to look at 
potential updates on general policy lines.
 
This also makes it easier for users to understand how policies become as 
they are.

How to use:
-----------

 In order to test this you would need to do the following:
 1.) Make a debug.log for a SELinux policy creating a policy package - "make <policy>.pp" in the refpolicy folder.
 2.) Grab input from debug.log and parse it with  the policy-parser script - 
 "python policy-parser -i <directory of and name debug file> -o <desired output location>"
                                    or
 "./policy-parser -i <directory of and name of debug file> -o <desired output location>"
 3.) Set the symbolic link for python to python3.2 by running the command: 
             ln -f /usr/bin/python3.2 /usr/bin/python 
     or for Gentoo users:
	     eselect python list
	     Find the number corresponding to the version of python that is 3.2
	     eselect python set <corresponding number>
 4.) Create a database for the parsed output of SELinux source and definition records with the workflow component script -
 "python workflow -i <directory and name of parsed output from policy-parser> -o <desired output location for database>"
                                                           or
 "./workflow -i <directory and name of parsed output from policy-parser> -o <desired output location for database>"

Note:
-----

In order to find the label class of class labels and permission labels two separate files called "SELinux Class List" and "SELinux Perms list". If for any reason these change with an update to SELinux or you add your own perms and classes and would like seorigin to classify them as such then you must add them to these files.

Debugging:
----------

To debug in the workflow component one can make use of the writeOut() function.

	To debug: 
	---------
	In any function():
	create string output = '' at beginning of function
	Assign whatever variable you would like as output += <variable>
	at the end of the function be sure to return output.

	In main():
	use function writeOut( outputFile, output )
	outputFile being the location of where you would like the file to be located.

This will write the output of the parsing to where you would like it to be located.

ex.) writeOut('/home/twitch153/seorigin/debug.txt', output)

Contributors
------------

	Devan Franchini		<oot153@gmail.com>
	Anthony G. Basile	<blueness@gentoo.org>
	Sven Vermuelen 		<swift@gentoo.org>

Bug Reporting:
--------------

	For now please submit bug reports by email to the contributors.