Adding New Permissions - Revision history

StephenSmalley at 18:32, 5 October 2009

StephenSmalley — Mon, 05 Oct 2009 18:32:55 GMT

←Older revision		Revision as of 18:32, 5 October 2009
Line 12:		Line 12:
	definitions will be automatically generated during the kernel build. If not defined in the policy, then		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,		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).	+	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.		<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>		</ol>
Line 19:		Line 19:
	<ol>		<ol>
	<li>Edit refpolicy/policy/flask/security_classes and/or access_vectors and add your definitions, typically at the end of the existing lists.		<li>Edit refpolicy/policy/flask/security_classes and/or access_vectors and add your definitions, typically at the end of the existing lists.
-	<li>make LINUX_D=/path/to/linux-2.6 tokern<br>	+	<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~~. The class and/or permission definition in the policy must line up with the definitions used in the kernel~~.	+	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>		</ol>
-
-	There is also the backward compatibility issue - we must not break
-	akpm's system if he boots a new kernel on an existing distro that lacks
-	new policy. This is generally handled via handle_unknown==allow or via policy capabilities.

	</p>		</p>

StephenSmalley at 14:58, 5 October 2009

StephenSmalley — Mon, 05 Oct 2009 14:58:29 GMT

←Older revision		Revision as of 14:58, 5 October 2009
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>

-	<~~br /~~>	+	<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>
-	<br />	+

	<p>		<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).
		+	<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>

-		+	Old way (for kernel < 2.6.33):
-	<~~pre~~>	+	<ol>
-	~~To add a new permission to SELinux:~~	+	<li>Edit refpolicy/policy/flask/security_classes and/or access_vectors and add your definitions, typically at the end of the existing lists.
-	~~1) checkout a copy of the refpolicy from oss.tresys.com or build prep the rawhide selinux policy src rpm~~	+	<li>make LINUX_D=/path/to/linux-2.6 tokern<br>
-	~~2) cd~~ refpolicy/policy/flask/	+	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. The class and/or permission definition in the policy must line up with the definitions used in the kernel.
-	~~3) edit~~ access_vectors and add your ~~definition~~	+	</ol>
-	~~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~~.	+

	There is also the backward compatibility issue - we must not break		There is also the backward compatibility issue - we must not break
	akpm's system if he boots a new kernel on an existing distro that lacks		akpm's system if he boots a new kernel on an existing distro that lacks
-	new policy.	+	new policy. This is generally handled via handle_unknown==allow or via policy capabilities.

-	</pre>
	</p>		</p>

EricParis at 03:16, 15 July 2008

EricParis — Tue, 15 Jul 2008 03:16:35 GMT

←Older revision		Revision as of 03:16, 15 July 2008
Line 9:		Line 9:
	<pre>		<pre>
	To add a new permission to SELinux:		To add a new permission to SELinux:
-	1) checkout a copy of the refpolicy from oss.tresys.com	+	1) checkout a copy of the refpolicy from oss.tresys.com or build prep the rawhide selinux policy src rpm
	2) cd refpolicy/policy/flask/		2) cd refpolicy/policy/flask/
	3) edit access_vectors and add your definition		3) edit access_vectors and add your definition

WikiSysop: 6 revision(s)

WikiSysop — Tue, 13 May 2008 09:54:57 GMT

6 revision(s)

←Older revision

Revision as of 09:54, 13 May 2008

JamesMorris at 21:43, 9 March 2008

JamesMorris — Sun, 09 Mar 2008 21:43:19 GMT

←Older revision		Revision as of 21:43, 9 March 2008
Line 1:		Line 1:
	(from [http://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])		(from [http://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])
		+
		+	<br />
		+	<br />

	<p>		<p>

JamesMorris at 21:42, 9 March 2008

JamesMorris — Sun, 09 Mar 2008 21:42:56 GMT

←Older revision		Revision as of 21:42, 9 March 2008
Line 2:		Line 2:

	<p>		<p>
		+
		+
	<pre>		<pre>
	To add a new permission to SELinux:		To add a new permission to SELinux:

JamesMorris at 21:41, 9 March 2008

JamesMorris — Sun, 09 Mar 2008 21:41:59 GMT

←Older revision		Revision as of 21:41, 9 March 2008
Line 1:		Line 1:
	(from [http://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])		(from [http://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])

		+	<p>
	<pre>		<pre>
	To add a new permission to SELinux:		To add a new permission to SELinux:
Line 19:		Line 20:

	</pre>		</pre>
		+	</p>

JamesMorris at 21:41, 9 March 2008

JamesMorris — Sun, 09 Mar 2008 21:41:24 GMT

←Older revision		Revision as of 21:41, 9 March 2008
Line 1:		Line 1:
-	(from [~~linkhttp~~://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])	+	(from [http://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])

	<pre>		<pre>

JamesMorris at 21:41, 9 March 2008

JamesMorris — Sun, 09 Mar 2008 21:41:05 GMT

←Older revision		Revision as of 21:41, 9 March 2008
Line 1:		Line 1:
	(from [linkhttp://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])		(from [linkhttp://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])

		+	<pre>
	To add a new permission to SELinux:		To add a new permission to SELinux:
	1) checkout a copy of the refpolicy from oss.tresys.com		1) checkout a copy of the refpolicy from oss.tresys.com
Line 16:		Line 17:
	akpm's system if he boots a new kernel on an existing distro that lacks		akpm's system if he boots a new kernel on an existing distro that lacks
	new policy.		new policy.
		+
		+	</pre>

JamesMorris: Added page on adding new permissions

JamesMorris — Sun, 09 Mar 2008 21:40:39 GMT

Added page on adding new permissions

New page

(from [linkhttp://marc.info/?l=selinux&m=120491447421303&w=2 this mailing list post])

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.

There is also the backward compatibility issue - we must not break
akpm's system if he boots a new kernel on an existing distro that lacks
new policy.