Adding New Permissions

From SELinux Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 21:41, 9 March 2008 (edit)
JamesMorris (Talk | contribs)

← Previous diff
Current revision (18:32, 5 October 2009) (edit) (undo)
StephenSmalley (Talk | contribs)

 
(5 intermediate revisions not shown.)
Line 1: Line 1:
-(from [http://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])+<p>To develop patches for the kernel security subsystem, use git to clone the security-testing-2.6 tree, as described at: http://security.wiki.kernel.org/index.php/Kernel_Repository</p>
-<p>+<p>To develop patches for the SELinux reference policy, use git to clone the refpolicy tree via git clone http://oss.tresys.com/git/refpolicy.git</p>
-<pre>+
-To add a new permission to SELinux:+
-1) checkout a copy of the refpolicy from oss.tresys.com+
-2) cd refpolicy/policy/flask/+
-3) edit access_vectors and add your definition+
-4) run make+
-5) run make LINUX_D=/path/to/linux-2.6 tokern to push the kernel headers+
-to your kernel tree+
-6) run make LIBSELINUX_D=/path/to/libselinux tolib to push the+
-libselinux headers to your libselinux tree.+
-Then you can generate patches against policy, kernel, and libselinux.+<p>
 +To add a new class and/or permission to the SELinux kernel code:
 +<br>
 +New way (with dynamic class/perm discovery, scheduled for kernels >= 2.6.33):
 +<ol>
 +<li>Edit security/selinux/include/classmap.h in the kernel tree and add your definition.
 +This will define the class and/or permission for use in the kernel; the corresponding symbol
 +definitions will be automatically generated during the kernel build. If not defined in the policy, then
 +the class and/or permission will be handled in accordance with your policy's handle_unknown definition,
 +which can be reject (refuse to load the policy), deny (deny the undefined class/permission), or allow (allow the undefined class/permission). handle_unknown is set to allow in modern Fedora policies.
 +<li>Edit refpolicy/policy/flask/security_classes and/or access_vectors in the refpolicy tree and add your definition. This will define the class and permission for use in the policy. You generally need to add the class and/or permission at the end of the existing list of classes or permissions for that class for backward compatibility with older kernels. The class and/or permission definition in policy need not line up with the definition in the kernel's classmap, as the values will be dynamically mapped by the kernel. Then add allow rules as appropriate to the policy for the new permissions.
 +</ol>
-There is also the backward compatibility issue - we must not break+Old way (for kernel < 2.6.33):
-akpm's system if he boots a new kernel on an existing distro that lacks+<ol>
-new policy.+<li>Edit refpolicy/policy/flask/security_classes and/or access_vectors and add your definitions, typically at the end of the existing lists.
 +<li>cd refpolicy/policy/flask && make LINUX_D=/path/to/linux-2.6 tokern<br>
 +This will generate header files containing the symbolic definitions for the classes and/or permissions and copy them into the kernel tree located at /path/to/linux-2.6.
 +</ol>
-</pre> 
</p> </p>

Current revision

To develop patches for the kernel security subsystem, use git to clone the security-testing-2.6 tree, as described at: http://security.wiki.kernel.org/index.php/Kernel_Repository

To develop patches for the SELinux reference policy, use git to clone the refpolicy tree via git clone http://oss.tresys.com/git/refpolicy.git

To add a new class and/or permission to the SELinux kernel code:
New way (with dynamic class/perm discovery, scheduled for kernels >= 2.6.33):

  1. Edit security/selinux/include/classmap.h in the kernel tree and add your definition. This will define the class and/or permission for use in the kernel; the corresponding symbol definitions will be automatically generated during the kernel build. If not defined in the policy, then the class and/or permission will be handled in accordance with your policy's handle_unknown definition, which can be reject (refuse to load the policy), deny (deny the undefined class/permission), or allow (allow the undefined class/permission). handle_unknown is set to allow in modern Fedora policies.
  2. Edit refpolicy/policy/flask/security_classes and/or access_vectors in the refpolicy tree and add your definition. This will define the class and permission for use in the policy. You generally need to add the class and/or permission at the end of the existing list of classes or permissions for that class for backward compatibility with older kernels. The class and/or permission definition in policy need not line up with the definition in the kernel's classmap, as the values will be dynamically mapped by the kernel. Then add allow rules as appropriate to the policy for the new permissions.

Old way (for kernel < 2.6.33):

  1. Edit refpolicy/policy/flask/security_classes and/or access_vectors and add your definitions, typically at the end of the existing lists.
  2. cd refpolicy/policy/flask && make LINUX_D=/path/to/linux-2.6 tokern
    This will generate header files containing the symbolic definitions for the classes and/or permissions and copy them into the kernel tree located at /path/to/linux-2.6.

Personal tools