http://selinuxproject.org/w/?title=RefpolicyWriteModule&limit=20&action=history&feed=atom RefpolicyWriteModule - Revision history 2024-03-28T17:43:54Z Revision history for this page on the wiki MediaWiki 1.23.13 http://selinuxproject.org/w/?title=RefpolicyWriteModule&diff=721&oldid=prev ChrisPeBenito: New page: = Getting Started with Reference Policy = This guide will walk you through the basics of creating a new reference policy module. This will also serve as an introduction to the basics conce... 2009-10-13T17:05:57Z <p>New page: = Getting Started with Reference Policy = This guide will walk you through the basics of creating a new reference policy module. This will also serve as an introduction to the basics conce...</p> <p><b>New page</b></p><div>= Getting Started with Reference Policy =<br /> This guide will walk you through the basics of creating a new reference policy<br /> module. This will also serve as an introduction to the basics concepts and<br /> philosophy of refpolicy. <br /> <br /> == Creating A Module ==<br /> Modules are the principal organizing component in refpolicy. A module contains<br /> the policy for an application or related group of applications, private and shared<br /> resources, labeling information, and interfaces that allow other modules access<br /> to the modules resources. The majority of the global policy has been eliminated<br /> in refpolicy. Certain policy components, like users and object classes, are<br /> still global in refpolicy, but almost all TE policy is now contained within a<br /> module. <br /> <br /> Let's create a new module called myapp. This is done by creating three files:<br /> myapp.te, mayapp.fc, and myapp.if. The file myapp.te file will contain all of<br /> the policy private to this module, including any types or attributes. The file<br /> myapp.fc file will contain the file context labeling statement for this module.<br /> Finally, the file myapp.if will contain the interfaces for this module (interfaces<br /> will be explained below).<br /> <br /> === Module TE Policy ===<br /> First create myapp.te and add the following:<br /> <br /> policy_module(myapp,1.0)<br /> <br /> # Private type declarations<br /> type myapp_t;<br /> type myapp_exec_t;<br /> type myapp_log_t;<br /> type myapp_tmp_t;<br /> <br /> domain_type(myapp_t)<br /> domain_entry_file(myapp_t, myapp_exec_t)<br /> <br /> logging_log_file(myapp_log_t)<br /> <br /> files_tmp_file(myapp_tmp_t)<br /> <br /> This creates all of the types needed for this module, including a type for the<br /> process, executables, log files, and temporary files. The first thing to notice<br /> is that there are no attributes applied to any of these types. In refpolicy all<br /> types and attributes can only be referred to in the module that declares them.<br /> This means that it is not possible, for example, to directly refer to the domain<br /> attribute. Instead, macros in other modules are used to declare that a type will<br /> be used for a certain purpose. These macros will likely use attributes (but not<br /> necessarily), but it allows the module that declared the attribute to strictly<br /> control how it can be used. In this example interfaces are used to transform the<br /> types into a domain, entry file, log file, and temporary file.<br /> <br /> Let's expand this example further by allowing some access for these types. My<br /> application needs access between it's own types and access to read random numbers.<br /> The access between private types is written exactly the same way current policy<br /> rules are written, i.e.:<br /> <br /> allow myapp_t myapp_log_t:file append_file_perms;<br /> <br /> allow myapp_t myapp_tmp_t:file manage_file_perms;<br /> <br /> This allows myapp_t to write to it's private types, but it needs to be able to<br /> create its temporary files in /tmp. This requires a call to the files module.<br /> <br /> files_tmp_filetrans(myapp_t,myapp_tmp_t,file)<br /> <br /> This call to the files module allows myapp_t to create myapp_tmp_t files in<br /> the /tmp directory.<br /> <br /> === Module FC Policy ===<br /> The file contexts file lists files and the labels they should have. Create<br /> myapp.fc and add the following:<br /> <br /> /usr/bin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s0)<br /> <br /> The gen_context() macro has three parameters, the base SELinux label, the MLS level, and optionally the MCS category. When compiling a module, the macro will add the appropriate MLS/MCS part to the label when needed. In the above example, the file will have a level of s0 when compiled for a MLS policy, and no categories when compiled for MCS. If the level s5:c1 is needed for MLS, and category c0 is needed for MCS, the above line would become:<br /> <br /> /usr/bin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s5:c1,c0)<br /> <br /> Since the MCS policy has only one sensitivity (s0), this is automatically added by the gen_context() macro, and should not be added by the user. The raw category set must be specified, instead of the translated category set (e.g., &quot;SystemLow-SystemHigh&quot;).<br /> <br /> === Module IF Policy ===<br /> The interface file creates the macros that other modules will use to gain access to my resources. This allows the module that created the type or attribute to define appropriate uses. Additionally, it provides a single point for documentation. Create myapp.if and add the following:<br /> <br /> ## &lt;summary&gt;Myapp example policy&lt;/summary&gt;<br /> ## &lt;desc&gt;<br /> ## &lt;nowiki&gt;&lt;p&gt;&lt;/nowiki&gt;<br /> ## More descriptive text about myapp. The desc<br /> ## tag can also use p, ul, and ol<br /> ## html tags for formatting.<br /> ## &lt;nowiki&gt;&lt;/p&gt;&lt;/nowiki&gt;<br /> ## &lt;nowiki&gt;&lt;p&gt;&lt;/nowiki&gt;<br /> ## This policy supports the following myapp features:<br /> ## &lt;nowiki&gt;&lt;ul&gt;&lt;/nowiki&gt;<br /> ## &lt;nowiki&gt;&lt;li&gt;Feature A&lt;/li&gt;&lt;/nowiki&gt;<br /> ## &lt;nowiki&gt;&lt;li&gt;Feature B&lt;/li&gt;&lt;/nowiki&gt;<br /> ## &lt;nowiki&gt;&lt;li&gt;Feature C&lt;/li&gt;&lt;/nowiki&gt;<br /> ## &lt;nowiki&gt;&lt;/ul&gt;&lt;/nowiki&gt;<br /> ## &lt;nowiki&gt;&lt;/p&gt;&lt;/nowiki&gt;<br /> ## &lt;/desc&gt;<br /> <br /> ########################################<br /> ## &lt;summary&gt;<br /> ## Execute a domain transition to run myapp.<br /> ## &lt;/summary&gt;<br /> ## &lt;param name=&quot;domain&quot;&gt;<br /> ## &lt;summary&gt;<br /> ## Domain allowed to transition.<br /> ## &lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> #<br /> interface(`myapp_domtrans',`<br /> gen_requires(`<br /> type myapp_t, myapp_exec_t;<br /> ')<br /> <br /> domtrans_pattern($1,myapp_exec_t,myapp_t)<br /> ')<br /> <br /> ########################################<br /> ## &lt;summary&gt;<br /> ## Read myapp log files.<br /> ## &lt;/summary&gt;<br /> ## &lt;param name=&quot;domain&quot;&gt;<br /> ## &lt;summary&gt;<br /> ## Domain allowed to read the log files.<br /> ## &lt;/summary&gt;<br /> ## &lt;/param&gt;<br /> #<br /> interface(`myapp_read_log',`<br /> gen_requires(`<br /> type myapp_log_t;<br /> ')<br /> <br /> logging_search_logs($1)<br /> allow $1 myapp_log_t:file read_file_perms;<br /> ')<br /> <br /> The first interface allows other domains to do a domain transition to myapp_t, by executing a program labeled myapp_exec_t.<br /> <br /> The second interface allows other domains to read myapp's log files. Myapp's log files are in the /var/log directory, so the access to search the /var/log directory is also given by the interface. The gen_requires() macro is used to support loadable policy modules, and must explicitly list the type and attributes used by this interface. If object classes of a userland object manager are used, the class and the permissions used by the interface must also be listed.</div> ChrisPeBenito