* [gentoo-commits] proj/hardened-docs:master commit in: xml/, xml/selinux/
@ 2011-02-19 3:45 Francisco Blas Izquierdo Riera
0 siblings, 0 replies; 5+ messages in thread
From: Francisco Blas Izquierdo Riera @ 2011-02-19 3:45 UTC (permalink / raw
To: gentoo-commits
commit: c472c97c1eda9057e64802b2551cfccba6d4ff12
Author: klondike <klondike <AT> xiscosoft <DOT> es>
AuthorDate: Sat Feb 19 03:44:58 2011 +0000
Commit: Francisco Blas Izquierdo Riera <klondike <AT> xiscosoft <DOT> es>
CommitDate: Sat Feb 19 03:44:58 2011 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=c472c97c
Swift helps with policies too
---
xml/index.xml | 2 +-
xml/selinux/index.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xml/index.xml b/xml/index.xml
index e4e5b61..8f376f1 100644
--- a/xml/index.xml
+++ b/xml/index.xml
@@ -143,7 +143,7 @@ project:
<tr><ti>Chris Richards</ti><ti>gizmo</ti>
<ti>Policy development, support (SELinux)</ti></tr>
<tr><ti>Sven Vermeulen</ti><ti>SwifT</ti>
-<ti>Documentation writing, support (SELinux)</ti></tr>
+<ti>Documentation writing, policy development, support (SELinux)</ti></tr>
</table>
</body>
diff --git a/xml/selinux/index.xml b/xml/selinux/index.xml
index 9da1c1a..695dd55 100644
--- a/xml/selinux/index.xml
+++ b/xml/selinux/index.xml
@@ -93,7 +93,7 @@ project:
<tr><ti>Chris Richards</ti><ti>gizmo</ti>
<ti>Policy development, support</ti></tr>
<tr><ti>Sven Vermeulen</ti><ti>SwifT</ti>
-<ti>Documentation writing, support</ti></tr>
+<ti>Documentation writing, policy development, support</ti></tr>
</table>
</body>
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [gentoo-commits] proj/hardened-docs:master commit in: xml/, xml/selinux/
@ 2011-05-04 22:03 Francisco Blas Izquierdo Riera
0 siblings, 0 replies; 5+ messages in thread
From: Francisco Blas Izquierdo Riera @ 2011-05-04 22:03 UTC (permalink / raw
To: gentoo-commits
commit: ae722291b0652e1cf4d043b8bf1cae46ec977ebf
Author: klondike <klondike <AT> xiscosoft <DOT> es>
AuthorDate: Wed May 4 20:59:09 2011 +0000
Commit: Francisco Blas Izquierdo Riera <klondike <AT> xiscosoft <DOT> es>
CommitDate: Wed May 4 20:59:47 2011 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=ae722291
updating headers
---
xml/selinux-faq.xml | 2 +-
xml/selinux/hb-appendix-reference.xml | 2 +-
xml/selinux/hb-appendix-troubleshoot.xml | 2 +-
xml/selinux/hb-intro-concepts.xml | 2 +-
xml/selinux/hb-intro-enhancingsecurity.xml | 2 +-
xml/selinux/hb-intro-referencepolicy.xml | 2 +-
xml/selinux/hb-intro-virtualization.xml | 2 +-
xml/selinux/hb-using-commands.xml | 2 +-
xml/selinux/hb-using-enforcing.xml | 2 +-
xml/selinux/hb-using-install.xml | 2 +-
xml/selinux/hb-using-permissive.xml | 2 +-
xml/selinux/hb-using-policymodules.xml | 2 +-
xml/selinux/index.xml | 2 +-
xml/selinux/selinux-handbook.xml | 2 +-
14 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/xml/selinux-faq.xml b/xml/selinux-faq.xml
index cda3a15..6bcaa17 100644
--- a/xml/selinux-faq.xml
+++ b/xml/selinux-faq.xml
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header$ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux-faq.xml,v 1.2 2011/04/25 20:21:47 zorry Exp $ -->
<guide link="/proj/en/hardened/selinux-faq.xml" lang="en">
<title>Gentoo Hardened SELinux Frequently Asked Questions</title>
diff --git a/xml/selinux/hb-appendix-reference.xml b/xml/selinux/hb-appendix-reference.xml
index e0e93ff..e0c0423 100644
--- a/xml/selinux/hb-appendix-reference.xml
+++ b/xml/selinux/hb-appendix-reference.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-reference.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>1.3</version>
diff --git a/xml/selinux/hb-appendix-troubleshoot.xml b/xml/selinux/hb-appendix-troubleshoot.xml
index 0af5aca..96df785 100644
--- a/xml/selinux/hb-appendix-troubleshoot.xml
+++ b/xml/selinux/hb-appendix-troubleshoot.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-troubleshoot.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>0</version>
diff --git a/xml/selinux/hb-intro-concepts.xml b/xml/selinux/hb-intro-concepts.xml
index f1cbc71..4c070fb 100644
--- a/xml/selinux/hb-intro-concepts.xml
+++ b/xml/selinux/hb-intro-concepts.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-concepts.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>3</version>
diff --git a/xml/selinux/hb-intro-enhancingsecurity.xml b/xml/selinux/hb-intro-enhancingsecurity.xml
index aa8d16c..105bc59 100644
--- a/xml/selinux/hb-intro-enhancingsecurity.xml
+++ b/xml/selinux/hb-intro-enhancingsecurity.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-enhancingsecurity.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>1</version>
diff --git a/xml/selinux/hb-intro-referencepolicy.xml b/xml/selinux/hb-intro-referencepolicy.xml
index dd3a37a..59d29de 100644
--- a/xml/selinux/hb-intro-referencepolicy.xml
+++ b/xml/selinux/hb-intro-referencepolicy.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-referencepolicy.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>0</version>
diff --git a/xml/selinux/hb-intro-virtualization.xml b/xml/selinux/hb-intro-virtualization.xml
index 37e02ac..cf082e0 100644
--- a/xml/selinux/hb-intro-virtualization.xml
+++ b/xml/selinux/hb-intro-virtualization.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-virtualization.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>0</version>
diff --git a/xml/selinux/hb-using-commands.xml b/xml/selinux/hb-using-commands.xml
index ebe0afe..b9342f0 100644
--- a/xml/selinux/hb-using-commands.xml
+++ b/xml/selinux/hb-using-commands.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-commands.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>2</version>
diff --git a/xml/selinux/hb-using-enforcing.xml b/xml/selinux/hb-using-enforcing.xml
index 9f218cb..ca626c3 100644
--- a/xml/selinux/hb-using-enforcing.xml
+++ b/xml/selinux/hb-using-enforcing.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-enforcing.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>1</version>
diff --git a/xml/selinux/hb-using-install.xml b/xml/selinux/hb-using-install.xml
index 30dc495..18ab538 100644
--- a/xml/selinux/hb-using-install.xml
+++ b/xml/selinux/hb-using-install.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-install.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>5</version>
diff --git a/xml/selinux/hb-using-permissive.xml b/xml/selinux/hb-using-permissive.xml
index d537f85..ee50590 100644
--- a/xml/selinux/hb-using-permissive.xml
+++ b/xml/selinux/hb-using-permissive.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-permissive.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>4</version>
diff --git a/xml/selinux/hb-using-policymodules.xml b/xml/selinux/hb-using-policymodules.xml
index c27df36..cd773c9 100644
--- a/xml/selinux/hb-using-policymodules.xml
+++ b/xml/selinux/hb-using-policymodules.xml
@@ -4,7 +4,7 @@
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-install.xml,v 1.5 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-policymodules.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
<sections>
<version>1</version>
diff --git a/xml/selinux/index.xml b/xml/selinux/index.xml
index 524d918..41535f8 100644
--- a/xml/selinux/index.xml
+++ b/xml/selinux/index.xml
@@ -2,7 +2,7 @@
<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE project SYSTEM "/dtd/project.dtd">
-<!--$Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml,v 1.41 2009/07/22 13:38:18 pebenito Exp $-->
+<!--$Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml,v 1.43 2011/04/25 20:12:59 zorry Exp $-->
<project>
<name>SELinux</name>
diff --git a/xml/selinux/selinux-handbook.xml b/xml/selinux/selinux-handbook.xml
index 30d8fae..53e4cf1 100644
--- a/xml/selinux/selinux-handbook.xml
+++ b/xml/selinux/selinux-handbook.xml
@@ -1,7 +1,7 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE book SYSTEM "/dtd/book.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml,v 1.9 2010/06/25 16:07:19 pebenito Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml,v 1.11 2011/04/25 20:12:59 zorry Exp $ -->
<book link="selinux-handbook.xml">
<title>Gentoo SELinux Handbook</title>
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [gentoo-commits] proj/hardened-docs:master commit in: xml/, xml/selinux/
@ 2011-05-20 19:49 Sven Vermeulen
0 siblings, 0 replies; 5+ messages in thread
From: Sven Vermeulen @ 2011-05-20 19:49 UTC (permalink / raw
To: gentoo-commits
commit: cd74e124658cbec41d31767ee156bc238d8f865f
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Fri May 20 19:48:21 2011 +0000
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
CommitDate: Fri May 20 19:48:21 2011 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=cd74e124
Link to documents
---
xml/selinux-policy.xml | 4 ++--
xml/selinux/index.xml | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/xml/selinux-policy.xml b/xml/selinux-policy.xml
index c9d5218..3d5f273 100644
--- a/xml/selinux-policy.xml
+++ b/xml/selinux-policy.xml
@@ -2,8 +2,8 @@
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header$ -->
-<guide disclaimer="draft" link="/proj/en/hardened/selinux-policy.xml" lang="en">
-<title>Gentoo Hardened SELinux Policy</title>
+<guide link="/proj/en/hardened/selinux-policy.xml" lang="en">
+<title>Gentoo Hardened SELinux Development Policy</title>
<author title="Author">
<mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail>
diff --git a/xml/selinux/index.xml b/xml/selinux/index.xml
index 049baa5..22f0192 100644
--- a/xml/selinux/index.xml
+++ b/xml/selinux/index.xml
@@ -85,6 +85,8 @@ Develop and maintain SELinux documentation specific to the Gentoo distribution
<resource link="/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo SELinux Handbook (including installation)</resource>
<resource link="/proj/en/hardened/selinux-faq.xml">Gentoo SELinux FAQ</resource>
+<resource link="/proj/en/hardened/selinux-development.xml">Gentoo Hardened SELinux Development</resource>
+<resource link="/proj/en/hardened/selinux-policy.xml">Gentoo Hardened SELinux Development Policy</resource>
<!--
Roadmap
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [gentoo-commits] proj/hardened-docs:master commit in: xml/, xml/selinux/
@ 2012-05-04 20:08 Sven Vermeulen
0 siblings, 0 replies; 5+ messages in thread
From: Sven Vermeulen @ 2012-05-04 20:08 UTC (permalink / raw
To: gentoo-commits
commit: 3d9e6555032882cc363721a8c7c91da1f096fe0a
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Fri May 4 20:08:16 2012 +0000
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
CommitDate: Fri May 4 20:08:16 2012 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=3d9e6555
Adding blurb on selinuxfs and /selinux versus /sys/fs/selinux
---
xml/selinux-faq.xml | 31 +++++++++++++++++++++++++++++--
xml/selinux/hb-using-install.xml | 13 +++++++++++--
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/xml/selinux-faq.xml b/xml/selinux-faq.xml
index 965adca..5bb32b8 100644
--- a/xml/selinux-faq.xml
+++ b/xml/selinux-faq.xml
@@ -17,8 +17,8 @@ The FAQ is a collection of solutions found on IRC, mailinglist, forums or
elsewhere
</abstract>
-<version>21</version>
-<date>2012-04-05</date>
+<version>22</version>
+<date>2012-05-05</date>
<faqindex>
<title>Questions</title>
@@ -892,5 +892,32 @@ logon manager).
</body>
</section>
+<section id="selinuxfs">
+<title>What is SELinuxfs and where should it be?</title>
+<body>
+
+<p>
+The selinuxfs is, as the name suggest, the SELinux File System. It is a
+pseudo-filesystem, which means that it is represented through files and
+directories, but those files or directories are not on your disk, but generated
+by the Linux kernel every time you query it.
+</p>
+
+<p>
+The file system is used by the SELinux utilities as an interface to query the
+SELinux state, maintained by the Linux kernel.
+</p>
+
+<p>
+Historically (before <path>libselinux-2.1.9</path>), the mount point for the
+SELinux file system <e>had to be</e> <path>/selinux</path>. From
+<path>libselinux-2.1.9</path> onwards, the default location where the file
+system is looked for is <path>/sys/fs/selinux</path>, although the library still
+falls back to the original <path>/selinux</path> location if it cannot find it
+at the new place.
+</p>
+
+</body>
+</section>
</chapter>
</guide>
diff --git a/xml/selinux/hb-using-install.xml b/xml/selinux/hb-using-install.xml
index 037877e..85b2551 100644
--- a/xml/selinux/hb-using-install.xml
+++ b/xml/selinux/hb-using-install.xml
@@ -7,8 +7,8 @@
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-install.xml,v 1.4 2011/06/07 19:46:52 klondike Exp $ -->
<sections>
-<version>21</version>
-<date>2012-04-29</date>
+<version>22</version>
+<date>2012-05-05</date>
<section>
<title>Installing Gentoo (Hardened)</title>
@@ -296,6 +296,15 @@ tools or configurations that apply.
</li>
</ul>
+<p>
+Previously (before <path>sys-libs/libselinux-2.1.9</path> was stabilized) the
+location of the SELinux file system was <path>/selinux</path>. This location can
+still be used (the recent libselinux implementations are currently backwards
+compatible with it) but we recommend to use the new location when you can - and
+if this is your first installation, better to go with the latest one
+immediately ;-)
+</p>
+
</body>
</subsection>
<subsection>
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [gentoo-commits] proj/hardened-docs:master commit in: xml/, xml/selinux/
@ 2012-05-26 15:54 Sven Vermeulen
0 siblings, 0 replies; 5+ messages in thread
From: Sven Vermeulen @ 2012-05-26 15:54 UTC (permalink / raw
To: gentoo-commits
commit: 1439140807dfa46775a8b6fb1de0749ce665cb62
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Sat May 26 15:54:46 2012 +0000
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
CommitDate: Sat May 26 15:54:46 2012 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=14391408
Removing selinux stuff from overlay - main docs are in CVS, no major updates needed for the time coming. If needed, just copy back. therwise its dual work.
---
xml/selinux-faq.xml | 952 ---------------------------
xml/selinux/hb-intro-concepts.xml | 910 --------------------------
xml/selinux/hb-intro-enhancingsecurity.xml | 387 -----------
xml/selinux/hb-intro-referencepolicy.xml | 255 -------
xml/selinux/hb-intro-resources.xml | 111 ----
xml/selinux/hb-intro-virtualization.xml | 25 -
xml/selinux/hb-using-commands.xml | 492 --------------
xml/selinux/hb-using-configuring.xml | 981 ----------------------------
xml/selinux/hb-using-install.xml | 741 ---------------------
xml/selinux/hb-using-policies.xml | 520 ---------------
xml/selinux/hb-using-states.xml | 367 -----------
xml/selinux/hb-using-troubleshoot.xml | 349 ----------
xml/selinux/index.xml | 156 -----
xml/selinux/selinux-handbook.xml | 199 ------
14 files changed, 0 insertions(+), 6445 deletions(-)
diff --git a/xml/selinux-faq.xml b/xml/selinux-faq.xml
deleted file mode 100644
index 5fe99fe..0000000
--- a/xml/selinux-faq.xml
+++ /dev/null
@@ -1,952 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux-faq.xml,v 1.2 2011/04/25 20:21:47 zorry Exp $ -->
-
-<guide>
-<title>Gentoo Hardened SELinux Frequently Asked Questions</title>
-<author title="Author">
- <mail link="pebenito@gentoo.org">Chris PeBenito</mail>
-</author>
-<author title="Author">
- <mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail>
-</author>
-
-<abstract>
-Frequently Asked Questions on SELinux integration with Gentoo Hardened.
-The FAQ is a collection of solutions found on IRC, mailinglist, forums or
-elsewhere
-</abstract>
-
-<version>23</version>
-<date>2012-05-21</date>
-
-<faqindex>
-<title>Questions</title>
-<section>
-<title>Introduction</title>
-<body>
-
-<p>
-Using SELinux requires administrators a more thorough knowledge of their
-system and a good idea on how processes should behave. Next to the <uri
-link="/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo Hardened SELinux
-handbook</uri>, a proper FAQ allows us to inform and help users in their
-day-to-day SELinux experience.
-</p>
-
-<p>
-The FAQ is an aggregation of solutions found on IRC, mailinglists, forums
-and elsewhere. It focuses on SELinux integration on Gentoo Hardened, but
-general SELinux questions that are popping up regularly will be incorporated
-as well.
-</p>
-
-</body>
-</section>
-</faqindex>
-
-<chapter>
-<title>General SELinux Support Questions</title>
-<section id="features">
-<title>Does SELinux enforce resource limits?</title>
-<body>
-
-<p>
-No, resource limits are outside the scope of an access control system. If you
-are looking for this type of support, take a look at technologies like
-grsecurity, cgroups, pam and the like.
-</p>
-
-</body>
-</section>
-<section id="grsecurity">
-<title>Can I use SELinux with grsecurity (and PaX)?</title>
-<body>
-
-<p>
-Definitely, we even recommend it. However, it is suggested that grsecurity's
-ACL support is not used as it would be redundant to SELinux's access control.
-</p>
-
-</body>
-</section>
-<section id="pie-ssp">
-<title>Can I use SELinux and the hardened compiler (with PIE-SSP)?</title>
-<body>
-
-<p>
-Definitely. We also suggest to use PaX to take full advantage of the PIE
-features of the compiler.
-</p>
-
-</body>
-</section>
-<section id="rsbac">
-<title>Can I use SELinux and RSBAC?</title>
-<body>
-
-<p>
-Yes, SELinux and RSBAC can be used together, but it is not recommended.
-Both frameworks (RSBAC and the SELinux implementation on top of Linux' Linux
-Security Modules framework) have a slight impact on system performance.
-Enabling them both only hinders performance more, for little added value since
-they both offer similar functionality.
-</p>
-
-<p>
-In most cases, it makes more sense to use RSBAC without SELinux, or SELinux
-without RSBAC.
-</p>
-
-<!--
-If users are unclear, mention that you can compile both in and then try to
-only enable one (configuration wise), but that this has little benefit on
-the performance (since the hooks are there, the checks that are made are just
-a bit different but due to caching, the overhead of having it enabled versus
-disabled is small anyhow).
--->
-
-</body>
-</section>
-<section id="filesystem">
-<title>Can I use SELinux with any file system?</title>
-<body>
-
-<p>
-SELinux requires access to a file's security context to operate properly.
-To do so, SELinux uses <e>extended file attributes</e> which needs to be
-properly supported by the underlying file system. If the file system supports
-extended file attributes and you have configured your kernel to enable this
-support, then SELinux will work on those file systems.
-</p>
-
-<p>
-General Linux file systems, such as ext2, ext3, ext4, jfs, xfs and btrfs
-support extended attributes (but don't forget to enable it in the kernel
-configuration) as well as tmpfs (for instance used by udev). If your file
-system collection is limited to this set, then you should have no issues.
-</p>
-
-<p>
-Ancillary file systems such as vfat and iso9660 are supported too, but with
-an important caveat: all files in each file system will have the same SELinux
-security context information since these file systems do not support extended
-file attributes.
-</p>
-
-<p>
-Network file systems can be supported in the same manner as ancillary file
-systems (all files share the same security context). However, some development
-has been made in supported extended file attributes on the more popular file
-systems such as NFS. Although this is far from production-ready, it does look
-like we will eventually support these file systems on SELinux fully as well.
-</p>
-
-</body>
-</section>
-<section id="nomultilib">
-<title>Can I use SELinux with AMD64 no-multilib?</title>
-<body>
-
-<!-- FAQ might be removed in the future since it is now obvious -->
-
-<p>
-Yes, just use the <path>hardened/linux/amd64/no-multilib/selinux</path> profile
-and you're all set.
-</p>
-
-</body>
-</section>
-<section id="ubac">
-<title>What is UBAC exactly?</title>
-<body>
-
-<p>
-UBAC, or <e>User Based Access Control</e>, introduces additional constraints
-when using SELinux policy. Participating domains / types that are <e>both</e>
-marked as a <c>ubac_constrained_type</c> (which is an attribute) will only
-have the allowed privileges in effect if they both run with the same SELinux
-user context.
-</p>
-
-<pre caption="Domains and their SELinux user context">
-<comment># The SELinux allow rule</comment>
-allow foo_t bar_t:file { read };
-
-<comment># This will succeed:</comment>
-staff_u:staff_r:foo_t reads file with type staff_u:object_r:bar_t
-
-<comment># This will be prohibited:</comment>
-user_u:user_r:foo_t reads file with type staff_u:object_r:bar_t
-</pre>
-
-<p>
-Of course, this is not always the case. Besides the earlier mentioned
-requirement that both types are <c>ubac_constrained_type</c>, if the source
-domain is <c>sysadm_t</c>, then the constraint will not be in effect (the
-<c>sysadm_t</c> domain is exempt from UBAC constraints). Also, if the source
-or destination SELinux user is <c>system_u</c> then the constraint will also
-not be in effect.
-</p>
-
-</body>
-</section>
-</chapter>
-
-<chapter>
-<title>Using SELinux</title>
-<section id="enable_selinux">
-<title>How do I enable SELinux?</title>
-<body>
-
-<p>
-This is explained in the <uri
-link="/proj/en/hardened/selinux/selinux-handbook.xml">SELinux Handbook</uri>
-in the chapter on <e>Using Gentoo/Hardened SELinux</e>.
-</p>
-
-</body>
-</section>
-<section id="switch_status">
-<title>How do I switch between permissive and enforcing?</title>
-<body>
-
-<p>
-The easiest way is to use the <c>setenforce</c> command. With <c>setenforce
-0</c> you tell SELinux to run in permissive mode. Similarly, with
-<c>setenforce 1</c> you tell SELinux to run in enforcing mode.
-</p>
-
-<p>
-You can also add a kernel option <c>enforcing=0</c> or <c>enforcing=1</c>
-in the bootloader configuration (or during the startup routine of the system).
-This allows you to run SELinux in permissive or enforcing mode from the start
-of the system.
-</p>
-
-<p>
-The default state of the system is kept in <path>/etc/selinux/config</path>.
-</p>
-
-</body>
-</section>
-<section id="disable_selinux">
-<title>How do I disable SELinux completely?</title>
-<body>
-
-<p>
-It might be possible that running SELinux in permissive mode is not sufficient
-to properly fix any issue you have. To disable SELinux completely, you need to
-edit <path>/etc/selinux/config</path> and set <c>SELINUX=disabled</c>. Next,
-reboot your system.
-</p>
-
-<impo>
-When you have been running your system with SELinux disabled, you must boot
-in permissive mode first and relabel your entire file system. Activities ran
-while SELinux was disabled might have created new files or removed the labels
-from existing files, causing these files to be available without security
-context.
-</impo>
-
-</body>
-</section>
-<section id="matchcontext">
-<title>How do I know which file context rule is used for a particular file?</title>
-<body>
-
-<p>
-If you use the <c>matchpathcon</c> command, it will tell you what the security
-context for the given path (file or directory) should be, but it doesn't tell
-you which rule it used to deduce this. To do that, you can use <c>findcon</c>:
-</p>
-
-<pre caption="Using findcon">
-~# <i>findcon /etc/selinux/strict/contexts/files/file_contexts -p /lib64/rc/init.d</i>
-/.* system_u:object_r:default_t
-/lib64/rc/init\.d(/.*)? system_u:object_r:initrc_state_t
-/lib64/.* system_u:object_r:lib_t
-</pre>
-
-<p>
-When the SELinux utilities try to apply a context, they try to match the rule
-that is the most specific, so in the above case, it is the one that leads to the
-initrc_state_t context.
-</p>
-
-<p>
-The most specific means, in order of tests:
-</p>
-
-<ol>
- <li>
- If line A has a regular expression, and line B doesn't, then line B is more
- specific.
- </li>
- <li>
- If the number of characters before the first regular expression in line A is
- less than the number of characters before the first regular expression in
- line B, then line B is more specific
- </li>
- <li>
- If the number of characters in line A is less than in line B, then line B is
- more specific
- </li>
- <li>
- If line A does not map to a specific SELinux type, and line B does, then
- line B is more specific
- </li>
-</ol>
-
-<p>
-However, when you add your own file contexts (using <c>semanage</c>), this does
-not apply. Instead, tools like <c>restorecon</c> will take the <e>last</e> hit
-within the locally added file contexts! You can check the content of the
-locally added rules in <path>/etc/selinux/strict/contexts/files/file_contexts.local</path>
-(substitute <path>strict</path> with your SELinux type).
-</p>
-
-</body>
-</section>
-<section id="localpolicy">
-<title>How do I make small changes (additions) to the policy?</title>
-<body>
-
-<p>
-If you are interested in the Gentoo Hardened SELinux development itself, please
-have a look at the <uri link="/proj/en/hardened/selinux-development.xml">SELinux
-Development Guide</uri> and other documentation linked from the <uri
-link="/proj/en/hardened/selinux/index.xml">SELinux project page</uri>.
-</p>
-
-<p>
-However, you will eventually need to keep some changes on your policy, due to
-how you have configured your system or when you need to allow something that is
-not going to be accepted as a distribution-wide policy change. In that case,
-read on.
-</p>
-
-<p>
-Updates on the policy are only possible as long as you need to <e>allow</e>
-additional privileges. It is not possible to remove rules from the policy, only
-enhance it. To maintain your own set of additional rules, create a file in which
-you will keep your changes. In the next example, I will use the term
-<path>fixlocal</path>, substitute with whatever name you like - but keep it
-consistent. In the file (<path>fixlocal.te</path>) put in the following text
-(again, substitute <path>fixlocal</path> with your chosen name):
-</p>
-
-<pre caption="fixlocal.te content">
-policy_module(fixlocal, 1.0)
-
-require {
-<comment># Declarations of types, classes and permissions used</comment>
-
-}
-
-<comment># Declaration of policy rules</comment>
-</pre>
-
-<p>
-In this file, you can add rules as you like. In the next example, we add three
-rules:
-</p>
-
-<ol>
- <li>
- Allow <c>mozilla_t</c> the <c>execmem</c> privilege (based on a denial that
- occurs when mozilla fails to start)
- </li>
- <li>
- Allow <c>ssh_t</c> to connect to any port rather than just the SSH port
- </li>
- <li>
- Allows the <c>user_t</c> domain to send messages directly to the system
- logger
- </li>
-</ol>
-
-<pre caption="fixlocal.te content">
-policy_module(fixlocal, 1.0)
-
-require {
- type mozilla_t;
- type ssh_t;
- type user_t;
-
- class process { execmem };
-}
-
-<comment># Grant mozilla the execmem privilege</comment>
-allow mozilla_t self:process { execmem };
-
-<comment># Allow SSH client to connect to any port (as provided by the user through the
-# "ssh -p <portnum> ..." command)</comment>
-corenet_tcp_connect_all_ports(ssh_t)
-
-<comment># Allow the user_t domain to send messages to the system logger</comment>
-logging_send_syslog_msg(user_t)
-</pre>
-
-<p>
-If you need to provide raw allow statements (like the one above for the
-<c>mozilla_t</c> domain), make sure that the type (<c>mozilla_t</c>),
-class (<c>process</c>) and privilege (<c>execmem</c>) are mentioned in
-the <c>require { ... }</c> paragraph.
-</p>
-
-<p>
-When using interface names, make sure that the types (<c>ssh_t</c> and
-<c>user_t</c>) are mentioned in the <c>require { ... }</c> paragraph.
-</p>
-
-<p>
-To find the proper interface name (like <c>corenet_tcp_connect_all_ports</c>
-above), you can either look for it in the <uri
-link="http://oss.tresys.com/docs/refpolicy/api/">SELinux Reference Policy
-API</uri> online or, if <c>sec-policy/selinux-base-policy</c> is built with the
-<e>doc</e> USE flag, in <path>/usr/share/doc/selinux-base-policy-.*/html</path>.
-Of course, you can also ask for help in <c>#gentoo-hardened</c> on
-irc.freenode.net, the mailinglist, forums, etc. to find the proper rules and
-statements for your case.
-</p>
-
-<p>
-With the policy file created, you can then build it using the
-<path>Makefile</path> provided by the system:
-</p>
-
-<pre caption="Building a fixlocal.pp file">
-<comment>(This uses "strict" as the example policy type, substitute with your
-own)</comment>
-# <i>make -f /usr/share/selinux/strict/include/Makefile fixlocal.pp</i>
-</pre>
-
-<p>
-Then, if the builds succeeds, you can load it in memory. Once loaded, it will be
-loaded after every boot as well, so you do not need to repeat this over and over
-again.
-</p>
-
-<pre caption="Loading the policy">
-# <i>semodule -i fixlocal.pp</i>
-</pre>
-
-</body>
-</section>
-</chapter>
-
-<chapter>
-<title>SELinux Kernel Error Messages</title>
-<section id="register_security">
-<title>I get a register_security error message when booting</title>
-<body>
-
-<p>
-During boot-up, the following message pops up:
-</p>
-
-<pre caption="Kernel message on register_security">
-There is already a security framework initialized, register_security failed.
-Failure registering capabilities with the kernel
-selinux_register_security: Registering secondary module capability
-Capability LSM initialized
-</pre>
-
-<p>
-This is nothing to worry about (and perfectly normal).
-</p>
-
-<p>
-This means that the Capability LSM module couldn't register as the primary
-module, since SELinux is the primary module. The third message means that it
-registers with SELinux as a secondary module.
-</p>
-
-</body>
-</section>
-<section id="permission_not_defined">
-<title>I get a 'Permission ... in class ... not defined' message during booting</title>
-<body>
-
-<p>
-During boot-up, the following message is shown:
-</p>
-
-<pre caption="Kernel message on undefined permission(s)">
-SELinux: 2048 avtab hash slots, 16926 rules.
-SELinux: 2048 avtab hash slots, 16926 rules.
-SELinux: 6 users, 6 roles, 1083 types, 34 bools
-SELinux: 77 classes, 16926 rules
-SELinux: Permission read_policy in class security not defined in policy.
-SELinux: Permission audit_access in class file not defined in policy.
-SELinux: Permission audit_access in class dir not defined in policy.
-SELinux: Permission execmod in class dir not defined in policy.
-...
-SELinux: the above unknown classes and permissions will be denied
-SELinux: Completing initialization.
-</pre>
-
-<p>
-This means that the Linux kernel that you are booting supports permissions that
-are not defined in the policy (as offered through the
-<c>sec-policy/selinux-base-policy</c> package). If you do not notice any errors
-during regular operations, then this can be ignored (the permissions will be
-made part of upcoming policy definitions).
-</p>
-
-</body>
-</section>
-</chapter>
-<chapter>
-<title>SELinux and Gentoo</title>
-<section id="no_module">
-<title>I get a missing SELinux module error when using emerge</title>
-<body>
-
-<p>
-When trying to use <c>emerge</c>, the following error message is displayed:
-</p>
-
-<pre caption="Error message from emerge on the SELinux module">
-!!! SELinux module not found. Please verify that it was installed.
-</pre>
-
-<p>
-This indicates that the portage SELinux module is missing or damaged. Recent
-Portage versions provide this module out-of-the-box, but the security contexts
-of the necessary files might be wrong on your system. Try relabelling the files
-of the portage package:
-</p>
-
-<pre caption="Relabel all portage files">
-~# <i>rlpkg portage</i>
-</pre>
-
-</body>
-</section>
-<section id="loadpolicy">
-<title>I get 'FEATURES variable contains unknown value(s): loadpolicy'</title>
-<body>
-
-<p>
-When running emerge, the following error is shown:
-</p>
-
-<pre caption="Emerge error on loadpolicy">
-FEATURES variable contains unknown value(s): loadpolicy
-</pre>
-
-<p>
-This is a remnant of the older SELinux policy module set where policy packages
-might require this FEATURE to be available. This has however since long been
-removed from the tree.
-</p>
-
-<p>
-Please update your profile to a recent SELinux profile (one ending with
-<path>/selinux</path>) and make sure that <path>/etc/make.conf</path> does not
-have <c>FEATURES="loadpolicy"</c> set.
-</p>
-
-</body>
-</section>
-<section id="conflicting_types">
-<title>During rlpkg I get 'conflicting specifications for ... and ..., using ...'</title>
-<body>
-
-<p>
-When trying to relabel a package (<c>rlpkg packagename</c>) or system (<c>rlpkg
--a -r</c>) you get a message similar to the following:
-</p>
-
-<pre caption="rlpkg complaining about conflicting specifications">
-filespec_add: conflicting specifications for /usr/bin/getconf and
-/usr/lib64/misc/glibc/getconf/XBS5_LP64_OFF64, using
-system_u:object_r:lib_t
-</pre>
-
-<p>
-This is most likely caused by hard linked files. Remember, SELinux uses the
-extended attributes in the file system to store the security context of a file.
-If two separate paths point to the same file using hard links (i.e. the files
-share the same inode) then both files will have the same security context.
-</p>
-
-<p>
-The solution depends on the particular case; in order of most likely to happen
-and resolve:
-</p>
-
-<ol>
- <li>
- Although both files are the same, they are not used in the same context.
- In such cases, it is recommended to remove one of the files and then copy
- the other file back to the first (<c>rm B; cp A B</c>). This way, both
- files have different inodes and can be labelled accordingly.
- </li>
- <li>
- Both files are used for the same purpose; in this case, it might be better
- to label the file which would not be labelled correctly (say a binary
- somewhere in a <path>/usr/lib64</path> location) using <c>semanage</c>
- (<c>semanage fcontext -a -t correct_domain_t /usr/lib64/path/to/file</c>)
- </li>
-</ol>
-
-<p>
-It is also not a bad idea to report (after verifying if it hasn't been reported
-first) this on <uri link="https://bugs.gentoo.org">Gentoo's bugzilla</uri> so
-that the default policies are updated accordingly.
-</p>
-
-</body>
-</section>
-<section id="portage_libsandbox">
-<title>During package installation, ld.so complains 'object 'libsandbox.so'
-from LD_PRELOAD cannot be preloaded: ignored'</title>
-<body>
-
-<p>
-During installation of a package, you might see the following error message:
-</p>
-
-<pre caption="Error message during package installation">
->> Installing (1 of 1) net-dns/host-991529
->>> Setting SELinux security labels
-ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
-</pre>
-
-<p>
-This message should <e>only</e> occur after the <e>Setting SELinux security
-labels</e> message. It happens because SELinux tells glibc to disable
-<c>LD_PRELOAD</c> (and other environment variables that are considered
-potentially harmful) during domain transitions. Here, portage calls the
-<c>setfiles</c> command (part of a SELinux installation) and as such
-transitions from portage_t to setfiles_t, which clears the environment
-variable.
-</p>
-
-<p>
-We believe that it is safer to trust the SELinux policy here (as setfiles runs
-in its own confined domain anyhow) rather than updating the policy to allow
-transitioning between portage_t to setfiles_t without clearing these
-environment variables. Note that <e>libsandbox.so is not disabled during builds
-and merges</e>, only during the activity where Portage labels the files it
-just merged.
-</p>
-
-<p>
-So the error is in our opinion cosmetic and can be ignored (but sadly not
-hidden).
-</p>
-
-</body>
-</section>
-<section id="emergefails">
-<title>Emerge does not work, giving 'Permission denied: /etc/make.conf'</title>
-<body>
-
-<p>
-This is to be expected if you are not using the <c>sysadm_r</c> role. Any
-Portage related activity requires that you are in the <c>sysadm_r</c> role. To
-transition to the role, first validate if you are currently known as
-<c>staff_u</c> (or, if you added your own SELinux identities, a user that has
-the permission to transition to the <c>sysadm_r</c> role). Then run <c>newrole
--r sysadm_r</c> to transition.
-</p>
-
-<pre caption="Transitioning to sysadm_r">
-~$ <i>emerge --info</i>
-Permission denied: '/etc/make.conf'
-~$ <i>id -Z</i>
-staff_u:staff_r:staff_t
-~$ <i>newrole -r sysadm_r</i>
-Password: <comment># Enter your users' password</comment>
-</pre>
-
-<p>
-This is also necessary if you logged on to your system as root but through SSH.
-The default behavior is that SSH sets the lowest role for the particular user
-when logged on. And you shouldn't allow remote root logins anyhow.
-</p>
-
-</body>
-</section>
-<section id="cronfails">
-<title>Cron fails to load in root's crontab with message '(root) ENTRYPOINT
-FAILED (crontabs/root)'</title>
-<body>
-
-<p>
-When you hit the mentioned error with a root crontab or an administrative
-users' crontab, but not with a regular users' crontab, then check the context of
-the crontab file:
-</p>
-
-<pre caption="Check context of the crontab file">
-~# <i>ls -Z /var/spool/cron/crontabs/root</i>
-staff_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root
-</pre>
-
-<p>
-Next, check what the default context is for the given user (in this case, root)
-when originating from the <c>crond_t</c> domain:
-</p>
-
-<pre caption="Check default context for user root">
-~# <i>getseuser root system_u:system_r:crond_t</i>
-seuser: root, level (null)
-Context 0 root:sysadm_r:cronjob_t
-Context 1 root:staff_r:cronjob_t
-</pre>
-
-<p>
-As you can see, the default context is always for the <c>root</c> SELinux user.
-However, the <path>/var/spool/cron/crontabs/root</path> file context in the
-above example is for the SELinux user staff_u. Hence, cron will not be able to
-read this file (the <c>user_cron_spool_t</c> type is a UBAC constrained one).
-</p>
-
-<p>
-To fix this, change the user of the file to root:
-</p>
-
-<pre caption="Change the SELinux user of the root crontab file">
-~# <i>chcon -u root /var/spool/cron/crontabs/root</i>
-</pre>
-
-<p>
-Another fix would be to disable UBAC completely. This is accomplished with
-<c>USE="-ubac"</c>.
-</p>
-
-</body>
-</section>
-<section id="missingdatum">
-<title>When querying the policy, I get 'ERROR: could not find datum for type ...'</title>
-<body>
-
-<p>
-When using <c>seinfo</c> or <c>sesearch</c> to query the policy on the system,
-you get errors similar to:
-</p>
-
-<pre caption="Triggering the 'could not find datum' error">
-~# <i>seinfo -tasterisk_t</i>
-ERROR: could not find datum for type asterisk_t
-</pre>
-
-<p>
-This is most likely because your tools are using a newer binary policy to
-enforce policy, but an older binary for querying. You can verify if this is the
-case by listing the last modification time on the files:
-</p>
-
-<pre caption="Checking last modification time of the policy files">
-~# <i>ls -ltr /etc/selinux/strict/policy/policy.*</i>
-</pre>
-
-<p>
-The file modified last should be the same one as returned by checking
-<path>/selinux/policyvers</path>:
-</p>
-
-<pre caption="Checking the runtime policy version">
-~# <i>cat /selinux/policyvers; echo</i>
-24
-</pre>
-
-<p>
-If this is not the case (which is very likely since you are reading this FAQ
-entry) then try forcing the utilities policy version to the correct version:
-</p>
-
-<pre caption="Editing semanage.conf">
-~# <i>vim /etc/selinux/semanage.conf</i>
-<comment># Look for and uncomment the policy-version line and set it to the right version</comment>
-policy-version = <i>24</i>
-</pre>
-
-<impo>
-If your system is upgrading its kernel, higher version(s) can be supported. In
-this case, either unset the value again to automatically "jump" to a higher
-version, or force set it to the higher version.
-</impo>
-
-</body>
-</section>
-<section id="recoverportage">
-<title>Portage fails to label files because "setfiles" does not work anymore</title>
-<body>
-
-<p>
-Portage uses the <c>setfiles</c> command to set the labels of the files it
-installs. However, that command is a dynamically linked executable, so any
-update in its depending libraries (<path>libselinux.so</path>,
-<path>libsepol.so</path>, <path>libaudit.so</path> and of course
-<path>libc.so</path>) might cause for the application to fail. Gentoo's standard
-solution (<c>revdep-rebuild</c>) will not work, since the tool will try to
-rebuild policycoreutils, which will fail to install because Portage cannot set
-the file labels.
-</p>
-
-<p>
-The solution is to rebuild policycoreutils while disabling Portage's selinux
-support, then label the installed files manually using <c>chcon</c>, based on
-the feedback received from <c>matchpathcon</c>.
-</p>
-
-<pre caption="Recovering from Portage installation failures">
-# <i>FEATURES="-selinux" emerge --oneshot policycoreutils</i>
-# <i>for FILE in $(qlist policycoreutils); do \
-CONTEXT=$(matchpathcon -n ${FILE}); chcon ${CONTEXT} ${FILE}; done</i>
-</pre>
-
-<p>
-Now Portage will function properly again, labeling files as they should.
-</p>
-
-</body>
-</section>
-<section id="nosuid">
-<title>Applications do not transition on a nosuid-mounted partition</title>
-<body>
-
-<p>
-If you have file systems mounted with the <c>nosuid</c> option, then
-applications started from these file systems will not transition into their
-appropriate domain. This is intentional.
-</p>
-
-<p>
-So, a <c>passwd</c> binary, although correctly labeled <e>passwd_exec_t</e>,
-will not transition into the <e>passwd_t</e> domain if the binary is stored on a
-file system mounted with <c>nosuid</c>.
-</p>
-
-</body>
-</section>
-<section id="auth-run_init">
-<title>Why do I always need to re-authenticate when operating init scripts?</title>
-<body>
-
-<p>
-When you, as an administrator, wants to launch or stop daemons, these activities
-need to be done as <c>system_u:system_r</c>. Switching to this context set is a
-highly privileged operation (since you are effectively leaving the user context
-and entering a system context) and hence the default setup requires the user to
-re-authenticate.
-</p>
-
-<p>
-You can ask not to re-authenticate if you use PAM by editing
-<path>/etc/pam.d/run_init</path> and adding the following line on top:
-</p>
-
-<pre caption="Setup run_init pam configuration to allow root not to re-authenticate">
-auth sufficient pam_rootok.so
-</pre>
-
-<p>
-With this in place, you can now prepend your init script activities with
-<c>run_init</c> and it will not ask for your password anymore:
-</p>
-
-<pre caption="Using run_init">
-# <i>run_init rc-service local status</i>
-Authenticating swift.
- * status: started
-</pre>
-
-</body>
-</section>
-<section id="initramfs">
-<title>How do I use SELinux with initramfs?</title>
-<body>
-
-<p>
-We currently do not support booting in enforcing mode with an initramfs image
-(but we are working on it). For the time being, boot in permissive mode. Once
-booted, switch to enforcing mode (<c>setenforce 1</c>).
-</p>
-
-<p>
-If you run SELinux on a production system and would not like to have attackers
-be able to switch back to permissive mode (even when they would have the
-necessary privileges otherwise), set the <c>secure_mode_policyload</c> boolean.
-When enabled, enforcing mode cannot be disabled anymore (until you reboot).
-</p>
-
-<pre caption="Toggling secure_mode_policyload">
-# <i>setsebool secure_mode_policyload on</i>
-</pre>
-
-</body>
-</section>
-<section id="xdm">
-<title>Logons through xdm (or similar) fail</title>
-<body>
-
-<p>
-If you log on through xdm, gdm, kdm, slim or any other graphical logon manager,
-you might notice in permissive mode that your context is off, and in enforcing
-mode that you just cannot log on.
-</p>
-
-<p>
-The reason of this is that PAM needs to be configured to include SELinux
-awareness in your session handling:
-</p>
-
-<pre caption="Updating pam setting for gdm">
-...
-session required pam_loginuid.so
-session optional pam_console.so
-<i>session optional pam_selinux.so</i>
-</pre>
-
-<p>
-Replicate the calls towards <path>pam_selinux.so</path> in the various
-<path>/etc/pam.d/gdm*</path> files (or similar depending on your graphical
-logon manager).
-</p>
-
-</body>
-</section>
-<section id="selinuxfs">
-<title>What is SELinuxfs and where should it be?</title>
-<body>
-
-<p>
-The selinuxfs is, as the name suggest, the SELinux File System. It is a
-pseudo-filesystem, which means that it is represented through files and
-directories, but those files or directories are not on your disk, but generated
-by the Linux kernel every time you query it.
-</p>
-
-<p>
-The file system is used by the SELinux utilities as an interface to query the
-SELinux state, maintained by the Linux kernel.
-</p>
-
-<p>
-Historically (before <path>libselinux-2.1.9</path>), the mount point for the
-SELinux file system <e>had to be</e> <path>/selinux</path>. From
-<path>libselinux-2.1.9</path> onwards, the default location where the file
-system is looked for is <path>/sys/fs/selinux</path>, although the library still
-falls back to the original <path>/selinux</path> location if it cannot find it
-at the new place.
-</p>
-
-<p>
-However, the <path>/sys/fs/selinux</path> location currently has an issue for
-those systems not using an initramfs, as it means that <path>/sys</path> has not
-been mounted when <c>init</c> tries to mount <path>/sys/fs/selinux</path>. We
-are working out how to resolve this, but for now, keep <path>/selinux</path>
-active.
-</p>
-
-</body>
-</section>
-</chapter>
-</guide>
diff --git a/xml/selinux/hb-intro-concepts.xml b/xml/selinux/hb-intro-concepts.xml
deleted file mode 100644
index bc6f4c1..0000000
--- a/xml/selinux/hb-intro-concepts.xml
+++ /dev/null
@@ -1,910 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-concepts.xml,v 1.4 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>6</version>
-<date>2012-04-29</date>
-
-<section>
-<title>Introduction</title>
-<subsection>
-<title>SELinux Concepts</title>
-<body>
-
-<p>
-Since SELinux is a MAC system, you should already figure out that managing
-SELinux-based permissions and rights might be a bit more challenging than
-managing the discretionary access control rights generally used on a Linux
-system. What is more is that SELinux works <b>on top of</b> the DAC system
-everybody is used from Linux. As a system administrator, you will need to be
-acquainted with some of the concepts and structures that SELinux has put in
-place in order to manage the access on the SELinux system.
-</p>
-
-<p>
-Describing those concepts is the purpose of this particular chapter. We will
-give examples on the various concepts from a SELinux enabled Gentoo Hardened
-system. However, do not fear if the use of particular commands is not explained
-sufficiently. They are currently meant as examples (their output is more
-important) and will be discussed further in this document.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>SELinux Policies</title>
-<body>
-
-<p>
-Within Gentoo (and other distributions as well), SELinux is supported through
-several policy levels. These are, in climbing order of complexity (meaning they
-can offer more security, but are harder to manage):
-</p>
-
-<ol>
- <li>
- <b>targeted</b> is a policy where network-facing services (daemons) are
- confined (the processes can only execute those actions that are defined
- in the policy), but other applications are running what is called
- <e>unconfined</e>, meaning that there are little to no restrictions for
- those processes.
- </li>
- <li>
- <b>strict</b> is a policy where all processes are confined. There are no
- unconfined domains. In other distributions, this is still considered the
- <e>targeted</e> policy but without the unconfined domain definition.
- </li>
- <li>
- <b>multi-category security</b> is a policy where the (confined) domains can
- be categorized (split up), allowing for multiple processes running in
- different instances of a confined domain
- </li>
- <li>
- <b>multi-level security</b> is a policy where rules exist regarding the
- sensitivity of domains and resources. This allows for a "proper"
- information flow policy (make sure that sensitive data isn't leaked
- to less privileged domains). Conceptually, one can understand this best
- if one considers sensitivity levels of Public, Internal, Confidential,
- Strictly Confidential, etc.
- </li>
-</ol>
-
-<p>
-When using Gentoo Hardened, all these policies are available. However,
-development focuses mainly on <e>strict</e> and <e>mcs</e>. The
-<e>targeted</e> policy is assumed to work if strict works whereas we know
-that the <e>mls</e> policy is currently not fit yet for production use.
-</p>
-
-<note>
-To clear up some confusion, especially when trying to seek support outside
-Gentoo: our "strict" implementation is not what was "strict" up to the year
-2008. The old meaning of strict involved a different implementation of the
-policy.
-</note>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>Security Contexts</title>
-<subsection>
-<title>Users, Roles, Domains, Sensitivities and Categories</title>
-<body>
-
-<p>
-One of the first concepts you will need to be acquainted with is the concept of
-a <e>security context</e>. This is a state given to a resource that uniquely
-identifies which grants (permissions) are applicable to the resource. This
-context is extremely important for SELinux as it is the definition on which it
-bases its permissions (grants or denials). When a resource has no security
-context assigned, SELinux will try to give it a default security context which -
-in the spirit of lowest privilege - has little permissions to perform any actions.
-</p>
-
-<p>
-Within SELinux, such a security context is displayed using three to five
-definitions, depending on the type of policy you are running:
-</p>
-
-<dl>
- <dt>user</dt>
- <dd>
- This is the <e>SELinux user</e> (which is not the same as the Linux/Unix
- technical user) assigned to the resource
- </dd>
- <dt>role</dt>
- <dd>
- This is the SELinux role in which the resource currently works
- </dd>
- <dt>type</dt>
- <dd>
- This is the type assigned to the resource and is the key to SELinux'
- enforcement rules
- </dd>
- <dt>sensitivity</dt>
- <dd>
- This is a level given to a resource informing the system about the
- sensitivity of this resource. A sensitivity is something akin to
- Public, Internal, Restricted, Confidential, Strictly Confidential, ...
- Sensitivity levels are only supported in MLS policies.
- </dd>
- <dt>category</dt>
- <dd>
- This is a specific instantiation of a resource. It allows segregation of
- resources even if they are of the same type. More about categories later -
- categories are supported in MLS and MCS policies.
- </dd>
-</dl>
-
-<p>
-More information on these particular definitions is given throughout the
-remainder of this chapter.
-</p>
-
-
-<p>
-As an example let's take a look at the security context of a logged on user:
-</p>
-
-<pre caption="Getting the security context of a logged on user">
-~$ <i>id -Z</i>
-staff_u:staff_r:staff_t
-</pre>
-
-<p>
-In this case, the user is identified as the SELinux user <e>staff_u</e>,
-currently in the <e>staff_r</e> role and assigned to the <e>staff_t</e>
-type. The actions the user is allowed to do are based upon this security
-context. Also, you notice that only three identifiers are shown. This is
-because the example is taken on a <e>strict</e> (or <e>targeted</e>) policy
-system. The next example gives the same result, but on an <e>MCS</e> policy
-system.
-</p>
-
-<pre caption="Getting the security context of a logged on user on an MCS policy system">
-~$ <i>id -Z</i>
-staff_u:staff_r:staff_t:s0-s0:c0.c1023
-</pre>
-
-<p>
-Here, the user is running with sensitivity level of s0 (which, in an MCS policy
-system, is the only available sensitivity) and with a category set of c0 up to
-and including c1023. However, note that in an MCS policy system categories are
-optional, so you might just see an output of <e>staff_u:staff_r:staff_t:s0</e>.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Access Control Policy</title>
-<body>
-
-<p>
-As mentioned before, these security contexts are used as the base for the
-permission rules. What SELinux does is check the security context of the source
-(for instance a process) and the destination (for instance a file that that
-process wants to read). It then checks if the requested operation (read) is
-allowed between those two contexts. Keep in mind though that SELinux works on
-top of the standard permission system used by Linux. If a process is not able to
-read a file to begin with, SELinux is not even consulted.
-</p>
-
-<p>
-Now, where the security context defines the state of a resource, we have not
-spoken about the resources themselves. Within SELinux, the resource types are
-defined as <e>object classes</e>. Common examples are <e>file</e> or <e>dir</e>,
-but SELinux also manages classes such as <e>filesystem</e>, <e>tcp_socket</e>,
-<e>process</e>, <e>sem</e> (semaphores) and more.
-</p>
-
-<p>
-On each object class, a set of <e>permissions</e> is declared which are possible
-against a resource within this object class. For instance, the <e>process</e>
-object class supports at least the following permissions:
-</p>
-
-<pre caption="Supported permissions against a 'process' resource">
-~# <i>ls /selinux/class/process/perms</i>
-dyntransition getcap rlimitinh setpgid siginh
-execheap getpgid setcap setrlimit sigkill
-execmem getsched setcurrent setsched signal
-execstack getsession setexec setsockcreate signull
-fork noatsecure setfscreate share sigstop
-getattr ptrace setkeycreate sigchld transition
-</pre>
-
-<p>
-The most common SELinux access control rule (<e>allow</e>) is described as
-follows:
-</p>
-
-<pre caption="SELinux allow statement">
-allow ACTOR TARGET:CLASS PRIVILEGE;
- +-+-+ +-+--+ +-+-+ +---+---+
- | | | `- Permission to be granted (like "write")
- | | `- Class on which permission is given (like "file")
- | `- Resource (label) on which permission is valid (like "portage_conf_t")
- `- Actor (domain) which gets the privilege (like "sysadm_t")
-</pre>
-
-<p>
-Let's take a look at a small example to explain the permission rules and how
-SELinux uses them. The example user is in the <e>staff_u:staff_r:staff_t</e>
-context and wants to write to its own home directory. As we can expect, this
-should be allowed. Don't worry about the commands here, we'll discuss them more
-properly further in this document.
-</p>
-
-<pre caption="Seeing if a user can write to its own home directory">
-<comment>(Show the security context for the users' home directory)</comment>
-~$ <i>ls -dZ ${HOME}</i>
-staff_u:object_r:user_home_dir_t /home/swift
-
-<comment>(Find the allow-rule which allows the staff_t type to write into a
- directory with the user_home_dir_t type)</comment>
-~$ <i>sesearch -s staff_t -t user_home_dir_t -c dir -p write -A</i>
-Found 1 semantic av rules:
- allow staff_t user_home_dir_t : dir { ioctl read write create ... };
-</pre>
-
-<p>
-As expected, the security context of the user (to be more specific, the domain
-in which it resides) has write access to the domain of the target's directories.
-The notion of <e>domain</e> is frequently used in SELinux documentation and
-refers to the type assigned to a process. BTW, as files do not have roles,
-they are given the default <e>object_r</e> role by SELinux.
-</p>
-
-<p>
-Now take a look at the following example. Our user, who is inside the portage
-group, wants to write to the <path>/var/tmp/portage</path> directory:
-</p>
-
-<pre caption="Seeing if a user can write to the /var/tmp/portage directory">
-~$ <i>id -a</i>
-uid=1001(swift) gid=100(users) groups=100(users),...,250(portage),...
-~$ <i>ls -ldZ /var/tmp/portage</i>
-drwxrwxr-x. 3 portage portage system_u:object_r:portage_tmp_t 4096 Dec 6 21:08 /var/tmp/portage
-</pre>
-
-<p>
-From the standard Linux permissions, the user has write access. But does SELinux
-also grant it?
-</p>
-
-<pre caption="Trying to write into /var/tmp/portage">
-~$ <i>sesearch -s staff_t -t portage_tmp_t -c dir -p write -A</i>
-~$
-<comment>(Notice that there is no output given here)</comment>
-~$ <i>touch /var/tmp/portage/foo</i>
-touch: cannot touch '/var/tmp/portage/foo': Permission denied
-</pre>
-
-<p>
-As SELinux could not find a rule that allows the staff_t domain to write to any
-directory labeled with the portage_tmp_t type, the permission was denied.
-</p>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>Type Enforcements / Domain Types</title>
-<subsection>
-<title>Types and Domains</title>
-<body>
-
-<p>
-To explain how the permission rules work and how this is enforced through the
-security contexts, let's start from the last definition in the context (the
-<e>type</e>) and work our way forward through the roles and users.
-</p>
-
-<ul>
- <li>
- A <e>SELinux type</e> is a particular label assigned to a resource. The
- <c>passwd</c> command for instance is labeled with the passwd_exec_t type.
- </li>
- <li>
- A <e>SELinux domain</e> is the security state of a process and identifies the rights
- and permissions it has. It is most often referred to by its type declaration.
- For instance, for a running <c>passwd</c> command, its domain is passwd_t.
- </li>
-</ul>
-
-<p>
-The rules that identify the allowed actions for a domain have been described earlier. Again:
-</p>
-
-<pre caption="Standard SELinux policy rules">
-allow <src_domain> <dst_type> : <class> { permission [ permission [ ... ] ] } ;
-</pre>
-
-<p>
-An example for the <e>passwd_t</e> domain would be the permissions granted
-between the <e>passwd_t</e> domain and the <e>shadow_t</e> type (used by the
-<path>/etc/shadow</path> file).
-</p>
-
-<pre caption="Grants between passwd_t and shadow_t">
-allow passwd_t shadow_t : file { ioctl read write create ... } ;
-</pre>
-
-<p>
-This permission syntax is very powerful, but also difficult. To have a secure
-system where normal behavior is allowed, you need to seriously fine-tune these
-rules for each and every application (and thus domain) that your system wants to
-host. Giving too broad permissions to a domain on a particular type might result
-in unauthorized activity being granted. Giving too few permissions might result
-in loss of efficiency or even effectiveness.
-</p>
-
-<p>
-To support easier grant rules, SELinux allows grouping of types using type
-attributes. For instance, the attribute <e>exec_type</e> bundles all types
-that are assigned to executable files (such as <e>bin_t</e>, <e>ssh_exec_t</e>,
-...), whereas the <e>file_type</e> attribute bundles all types that are
-assigned to regular files. Although this can simplify rule management, it makes
-it easier to grant too many permissions.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Domain Transitions</title>
-<body>
-
-<p>
-So far for types, domain definitions and their permissions. We have stated before
-that permissions are based on the domain in which a process resides. But how
-does a process become part of the domain? You might think that this happens by
-default (starting the <c>passwd</c> command would automatically bring the
-process in the <e>passwd_t</e> domain), but this is in fact a combination of
-three specific privileges that need to be granted:
-</p>
-
-<ol>
- <li>
- The current domain must be allowed to transition to a domain
- </li>
- <li>
- The target domain should have an <e>entry point</e>, which is an executable
- that is allowed to start in the domain
- </li>
- <li>
- The source domain should have <e>execute</e> rights on (the domain of) that
- executable
- </li>
-</ol>
-
-<impo>
-Not being allowed to transition does not mean that you cannot
-execute the binary. The binary can still be executed, but will not run inside
-the target domain. Instead, it will inherit the domain of the executor and hence
-the rights and permissions of this domain.
-</impo>
-
-<p>
-Through these rules, the security administrator of a system can more
-specifically control who and under which conditions particular actions can be
-taken.
-</p>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>Roles and Rights</title>
-<subsection>
-<title>The Role of a Role</title>
-<body>
-
-<p>
-The previously discussed domains and domain rules is quite powerful. However,
-this is not where SELinux stops. After all, you want to be able to deny access
-towards particular domains from unauthorized users. One requirement is of course
-not to allow transitions from the user domain to that restricted domain, but how
-can you enforce one set of users to be allowed and another to be denied?
-</p>
-
-<p>
-Enter the roles. By using roles, you can tell SELinux which domains are allowed
-for a role and which aren't. An example would be the <e>ifconfig_t</e> domain.
-This domain has the rights to change the networking interface definitions - not
-something you want to allow your users. And in fact, if you would verify,
-SELinux does not allow the user role <e>user_r</e> to be assigned with the
-<e>ifconfig_t</e> domain.
-</p>
-
-<pre caption="ifconfig_t domain and user_r versus sysadm_r">
-~$ <i>seinfo -ruser_r -x</i>
- user_r
- Dominated Roles:
- user_r
- Types:
- ...
-~$ <i>seinfo -rsysadm_r -x</i>
- sysadm_r
- Dominated Roles:
- sysadm_r
- Types:
- ...
- ifconfig_t
- ...
-</pre>
-
-<impo>
-Again, not being able to be associated with a domain does not mean that the
-<e>user_r</e> role cannot <e>execute</e> the <c>ifconfig</c> binary. It can, but
-it will execute the binary within its own domain (<e>user_t</e>) and as such
-will not have the rights to manipulate the networking interface (but will still
-be able to read the interface information albeit with limited output).
-</impo>
-
-<p>
-Roles are often used in access control systems to group permissions to a single
-functional set (the role) which can then be assigned to individuals (accounts).
-For instance, such access control systems create roles for accountants,
-operators, managers, ... and grant the appropriate privileges to these roles.
-Then, their users are assigned one (or sometimes multiple) roles and the users
-inherit the permissions assigned to these roles.
-</p>
-
-<p>
-With SELinux, the idea remains the same (use roles to functionally differentiate
-privileges) but is implemented differently: roles are assigned target domains
-in which a role is allowed to "be in". The permissions remain assigned to the
-domains.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Role Transitions</title>
-<body>
-
-<p>
-Users (and processes) have the ability to switch roles. This is allowed by
-SELinux, but of course only when the switch itself is granted. By default,
-the SELinux policy used by Gentoo Hardened offers five roles on a SELinux
-system:
-</p>
-
-<dl>
- <dt>object_r</dt>
- <dd>
- The <e>object_r</e> role is the only role by default available through
- SELinux. It is usually only assigned to resources where roles have no
- benefit or value (such as files and directories).
- </dd>
- <dt>system_r</dt>
- <dd>
- The <e>system_r</e> role is used for highly privileged system services.
- The <e>system_r</e> role is allowed to switch to any other "default" role.
- No role exception <e>sysadm_r</e> can switch to the <e>system_r</e> role.
- </dd>
- <dt>sysadm_r</dt>
- <dd>
- The <e>sysadm_r</e> role is used for system administration activities. The
- <e>sysadm_r</e> role is allowed to switch to any other "default" role. Only
- the <e>system_r</e> and <e>staff_r</e> roles are allowed to switch to the
- <e>sysadm_r</e> role.
- </dd>
- <dt>staff_r</dt>
- <dd>
- The <e>staff_r</e> role is used for system operators who might have the
- rights to perform system administration tasks. The <e>staff_r</e> role is
- only allowed to switch to the <e>sysadm_r</e> role. Only <e>sysadm_r</e> and
- <e>system_r</e> can switch to the <e>staff_r</e> role.
- </dd>
- <dt>user_r</dt>
- <dd>
- The <e>user_r</e> role is used for standard, unprivileged users. It is not
- allowed to transition towards any other role; only <e>sysadm_r</e> and
- <e>system_r</e> roles are allowed to switch to the <e>user_r</e> role.
- </dd>
-</dl>
-
-<note>
-A "default" role is any of <e>user_r</e>, <e>staff_r</e>, <e>sysadm_r</e> or
-<e>system_r</e>. If you create additional roles yourself, they are not part of
-the "default" roles.
-</note>
-
-<p>
-Using these definitions, a user inside the <e>user_r</e> role will never be able
-to execute <c>ifconfig</c> within the <e>ifconfig_t</e> domain. The use of the
-word <e>never</e> here is important: not even if the user is able to become
-root using <c>sudo</c> or any other command will he be able to run the
-<c>ifconfig</c> command in the <e>ifconfig_t</e> domain because, even after
-running <c>sudo</c>, he is still inside the <e>user_r</e> role.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>SELinux Users</title>
-<body>
-
-<p>
-A SELinux user is not the same as the Linux user. Whereas standard Linux user
-accounts can be switched using commands such as <c>su</c> or <c>sudo</c>, a
-SELinux user can not be changed. Even when you successfully execute <c>sudo</c>,
-your SELinux user will remain the same.
-</p>
-
-<p>
-When you look at a SELinux powered system, you might notice that that system
-doesn't use many SELinux users. For instance, Gentoo Hardened's default setup
-defines the users <e>root</e>, <e>user_u</e>, <e>staff_u</e>, <e>sysadm_u</e> and
-<e>system_u</e> and some systems never introduce any other SELinux user. But if
-that is the case, is the above advantage of SELinux users (once a user is logged
-on, he cannot change his SELinux user) the only one?
-</p>
-
-<p>
-Well, no. SELinux users are also used to categorize accounts which have the
-permission to use a particular role.
-</p>
-
-<pre caption="SELinux users and their associated roles">
-~# <i>semanage user -l</i>
-SELinux User SELinux Roles
-
-root staff_r sysadm_r
-staff_u staff_r sysadm_r
-sysadm_u sysadm_r
-system_u system_r
-user_u user_r
-</pre>
-
-<p>
-Standard Linux users are mapped to these SELinux users:
-</p>
-
-<pre caption="Linux users and their SELinux user mappings">
-~# <i>semanage login -l</i>
-Login Name SELinux User
-
-__default__ user_u
-root root
-swift staff_u
-</pre>
-
-<p>
-In this example, only logins of the Linux user <e>swift</e> (through
-<e>staff_u</e>) and <e>root</e> (through the <e>root</e> SELinux user)
-will be able to eventually run inside the <e>sysadm_r</e> role. All other
-Linux accounts will be by default mapped to the <e>user_u</e> user (and
-this <e>user_r</e> role).
-</p>
-
-<p>
-This is <e>only</e> applicable for interactive logins. Processes that are
-launched through an init script or otherwise do not automatically become part of
-the SELinux user <e>user_u</e>: depending on the security context of whatever
-process is starting them, they can become anything. Of course, if the security
-context of the process that is starting them is <e>user_u:user_r:user_t</e> then
-they will not be able to transform into anything other than
-<e>user_u:user_r:*</e> with <e>*</e> a domain supported by the <e>user_r</e>
-role.
-</p>
-
-<p>
-SELinux users are also used to implement <e>User Based Access Control</e> or
-<e>UBAC</e>. This SELinux functionality allows for domains to be SELinux user
-aware: a process running in the context of a particular SELinux user can then -
-for instance - only work with files of the same SELinux user. This offers a
-finer grained access method, because that process might run within a domain
-which has write access to the domain of the file, but can still not write to the
-file because the SELinux users' differ.
-</p>
-
-<p>
-At this moment, Gentoo Hardened SELinux' supports both policies with and
-without UBAC, although we strongly recommend to use UBAC. This is controlled
-through the <c>ubac</c> USE flag.
-</p>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>Multi Level Security / Multi Category Security</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-Next to the type enforcement feature, SELinux also offers MLS and MCS support.
-This allows administrators to define a hierarchical confidentiality policy.
-For instance, you can ensure that a user or process within a certain
-security domain and level can write to files with the same level (or higher), or
-read files with the same level (or lower), but not write files to a lower level.
-This allows administrators to implement some sort of
-public/internal/confidential/strictly confidential hierarchical security level
-for files.
-</p>
-
-<p>
-Although implementation of MLS is possible with the type enforcement rules we
-have previously explained, it would lead to an unmanageable collection of types
-and permissions. The MLS implementation simplifies this.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Multi-Level Security</title>
-<body>
-
-<p>
-The most flexible - but also most challenging to manage - method offered by
-SELinux is MLS, or <e>Multi-Level Security</e>. When using this policy type,
-security administrators can assign sensitivity labels to resources and define
-which domains (and which sensitivity levels) are able to read/write to which
-level. A level is always given as a range, showing the lowest and highest level
-that a particular domain is running in.
-</p>
-
-<p>
-Next to the sensitivity level, MLS supports categories on a per-level basis.
-These categories allow the security administrator to make different, possibly
-independent "containers" for sensitive resources. To give an example, the
-administrator can support the levels Public up to Strictly Confidential, and
-categories of "Finance", "Risk Analysis", "Acquisitions", "IT Systems", ...
-</p>
-
-<p>
-With such categories, one can then allow one role to have access to all
-sensitivity levels for a particular category (say "IT Systems") but still only
-have access to the Public and Internal documents of all other categories.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Multi-Category Security</title>
-<body>
-
-<p>
-The MCS or <e>Multi-Category Security</e> policy is a subset of the MLS policy.
-It supports the various categories, but without using the multiple security
-levels for the resources.
-</p>
-
-<p>
-The use of MCS has become popular because it is far less difficult to manage
-while still retaining some of the flexibilities offered by the MLS policy.
-Where MLS is more chosen for business purposes (and as such has some influence
-on the organization of the business), MCS is often used for <e>multitenancy</e>
-architectures. In a multi-tenant architecture, systems are running processes for
-various clients simultaneously. Categorisation allows for separation of
-privileges across these processes without introducing multiple domains (which
-would require the development of new policies for each new client that a system
-wants to serve).
-</p>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Reference Policy</title>
-<subsection>
-<title>About refpolicy</title>
-<body>
-
-<p>
-As described previously, SELinux uses type enforcement to describe the state of
-your system. This is done by giving each resource on your system (be it a
-process, a network port, a file or directory) a specific type and describe the
-rules how types can work with each other.
-</p>
-
-<p>
-Managing such a policy is not easy. Unlike some other MAC systems, which rely
-on a learning mode and do not use domain definitions (they rather keep track of
-which commands a process is allowed to execute), a proper SELinux definition
-requires lots (thousands and thousands) of permission lines.
-</p>
-
-<p>
-To ensure that no duplicate effort is made, and to help distributions like
-Gentoo, Fedora, RedHat, Debian, ... with their SELinux integration efforts, a
-project is launched called <e>The Reference Policy</e>.
-</p>
-
-<p>
-This project, managed by <uri
-link="http://oss.tresys.com/projects/refpolicy">Tresys</uri>, is used by almost
-all SELinux supporting distributions, including Gentoo Hardened, Fedora, RedHat
-Enterprise Linux, Debian, Ubuntu and more. This implementation not only offers
-the modular policies that users are looking for, but also enhances the SELinux
-experience with additional development tools that make it easier to work with
-the SELinux policies on your system. Updates in the reference policy eventually
-make it in all supported distributions. The same goes for Gentoo Hardened, which
-aims to use a policy as close as possible to the reference policy, and submits
-its own patches to the reference policy as well, which benefits the entire
-community.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Reference Policy API</title>
-<body>
-
-<p>
-One major advantage of the reference policy is its API. To help policy writers,
-the reference policy uses a macro language which generates the necessary allow
-(and other) rules. This macro language makes it a lot easier to add rights to
-particular domains. You can find the API documented <uri
-link="http://oss.tresys.com/docs/refpolicy/api/">online</uri>, but if you have
-USE="doc" set, it will be stored on your system as well the moment you install
-and configure SELinux.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Modular Approach</title>
-<body>
-
-<p>
-Another feature of the reference policy is its use of <e>modules</e>. If you
-would build all rules in a single policy (a binary file readable by the Linux
-kernel, allowing it to interpret and enforce SELinux rules), the file would
-quickly become too huge and inefficient.
-</p>
-
-<p>
-Instead, the reference policy defines the rules in what it calls modules, which
-define one domain (like <c>portage_t</c>) or more (if they are all tightly
-related) and the rights and privileges that that domain would need in order to
-function properly. Any right that the domain needs with respect to another
-domain needs to be defined through that domains' interfaces (see earlier),
-forcing the modules to be specific and manageable.
-</p>
-
-<pre caption="Example overview of installed SELinux modules">
-# <i>semodule -l</i>
-alsa 1.11.0
-apache 2.3.0
-audioentropy 1.6.0
-dbus 1.15.0
-dmidecode 1.4.0
-<comment>(...)</comment>
-</pre>
-
-<p>
-By using a modular approach, one only needs to load the base policy (kernel
-layer as well as other, core definitions) and the modules related to his system.
-You can then safely ignore the other modules. This improves performance (smaller
-policy, which also causes rebuilds to be a lot less painful) and manageability
-(properly defined boundaries for policy rules).
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Tunables and Conditionals</title>
-<body>
-
-<p>
-But wait, there's more. The reference policy also supports <e>booleans</e>.
-Those are flags that a security administrator can enable or disable to change
-the active policy. Properly defined booleans allow security administrators to
-fine-tune the policy for their system.
-</p>
-
-<pre caption="Overview of available booleans">
-# <i>getsebool -a</i>
-allow_execheap --> off
-allow_execmem --> off
-allow_execmod --> off
-allow_execstack --> off
-allow_gssd_read_tmp --> on
-allow_httpd_anon_write --> off
-</pre>
-
-<p>
-Booleans are an important part to make a generic reference policy which is still
-usable for the majority of SELinux users. Although they have specific
-requirements (such as allowing ptrace, or disallowing execmem) they can still
-use the same reference policy and only need to toggle the booleans they need.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Policy Files and Versions</title>
-<body>
-
-<p>
-The SELinux policy infrastructure that is used (i.e. the capabilities and
-functionalities that it offers) isn't in its first version. Currently, SELinux
-deployments use a binary version of 24 or 26 (depending on the kernel version
-used).
-</p>
-
-<pre caption="Getting the binary policy version">
-# <i>sestatus</i>
-SELinux status: enabled
-SELinuxfs mount: /selinux
-Current mode: enforcing
-Mode from config file: enforcing
-Policy version: 24
-Policy from config file: strict
-</pre>
-
-<p>
-Every time functionalities or capabilities are added which require
-changes to the internal structure of the compiled policy, this version is
-incremented. The following is an overview of the policy versions' history.
-</p>
-
-<dl>
- <dt>Version 12</dt>
- <dd>"Old API" for SELinux, which is now deprecated</dd>
- <dt>Version 15</dt>
- <dd>"New API" for SELinux, merged in Linux kernel 2.6.0 (until 2.6.5)</dd>
- <dt>Version 16</dt>
- <dd>Conditional policy extensions added (2.6.5)</dd>
- <dt>Version 17</dt>
- <dd>IPV6 support added (2.6.6 - 2.6.7)</dd>
- <dt>Version 18</dt>
- <dd>Fine-grained netlink socket support added (2.6.8 - 2.6.11)</dd>
- <dt>Version 19</dt>
- <dd>Enhanced multi-level security (2.6.12 - 2.6.13)</dd>
- <dt>Version 20</dt>
- <dd>Access vector table size optimizations (2.6.14 - 2.6.18)</dd>
- <dt>Version 21</dt>
- <dd>Object classes in range transitions (2.6.19 - 2.6.24)</dd>
- <dt>Version 22</dt>
- <dd>Policy capabilities (features) (2.6.25)</dd>
- <dt>Version 23</dt>
- <dd>Per-domain permissive mode (2.6.26 - 2.6.27)</dd>
- <dt>Version 24</dt>
- <dd>Explicit hierarchy (type bounds) (2.6.28 - 2.6.38)</dd>
- <dt>Version 25</dt>
- <dd>Filename based transition support (2.6.39)</dd>
- <dt>Version 26</dt>
- <dd>Role transition support for non-process classes (3.0)</dd>
-</dl>
-
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Next Steps</title>
-<subsection>
-<title>What Next</title>
-<body>
-
-<p>
-It might be difficult to understand now, but the concepts are important because,
-if something fails on your system when SELinux is enabled, but it doesn't fail
-when SELinux is disabled, then you will need to dive into the security contexts,
-rules, types and domain transitions to find out why.
-</p>
-
-<p>
-The next chapter in line will give you some background resource information
-(online resources, books, FAQs, etc.) After that, we'll dive into the
-installation and configuration of SELinux on your Gentoo Hardened system. Then,
-we'll configure and tune the SELinux policy to our needs.
-</p>
-
-</body>
-</subsection>
-</section>
-</sections>
diff --git a/xml/selinux/hb-intro-enhancingsecurity.xml b/xml/selinux/hb-intro-enhancingsecurity.xml
deleted file mode 100644
index 8a126c1..0000000
--- a/xml/selinux/hb-intro-enhancingsecurity.xml
+++ /dev/null
@@ -1,387 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-enhancingsecurity.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>2</version>
-<date>2011-05-25</date>
-
-<section>
-<title>Introduction</title>
-<subsection>
-<title>A Warm Welcome</title>
-<body>
-
-<p>
-Welcome to the Gentoo SELinux handbook. In this resource, we will bring you up
-to speed with Gentoo Hardened's implementation of SELinux and the policies
-involved. Part of this exercise is to help you understand why SELinux was
-brought to life and which concept is behind the development of the SELinux
-patches. We will cover the SELinux concepts, the reference policy that Gentoo
-Hardened uses and elaborate on how to work with the various SELinux tools.
-</p>
-
-<p>
-The purpose of this book is not to explain SELinux itself in great detail. There
-are many references available on the Internet and in the better bookstores that
-help you with the SELinux topic. Instead, we will focus on SELinux integration
-within Gentoo Hardened. Of course, we will give a quick introduction to SELinux
-to allow you to understand how it works, what it is and help you identify which
-actions you will need to take in order to properly secure your system using the
-SELinux tools.
-</p>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>Securing Linux</title>
-<subsection>
-<title>Security In General</title>
-<body>
-
-<p>
-Security is often seen as a vague concept. What is security in general? How do
-you measure security? What is the benefit and how do you make sure you do not
-put too much effort in securing your system?
-</p>
-
-<p>
-Well, security zealots will tell you that there is no such thing as too much
-security. If properly implemented, security does not restrict functionality or
-performance. It does not give you too much overhead in order to do your tasks.
-But implementing security properly is a different and time-consuming task. That
-is also why you often hear that security is as good as its administrator.
-</p>
-
-<p>
-So, how can you look at security? A good practice on security is to define your
-security goals. List what you want to achieve and why. By tracking the threats
-that you want to minimize, you build up a security model that is appropriate for
-your environment. Such threats can be very broad, such as "Ensure no-one is able
-to work around our security measures".
-</p>
-
-<p>
-In case of a Linux system powered with SELinux, this would at least mean that
-you want to protect critical system files, such as kernel image(s) and boot
-loader configuration, passwords and the SELinux policy binary itself from being
-written by anyone or anything except trusted processes.
-</p>
-
-</body>
-</subsection>
-<!-- Suggestion to remove from guide, more interesting for a generic security
-document?
-<subsection>
-<title>Security on Operating System Level</title>
-<body>
-
-<p>
-So far for the high-level and theoretic explanation on security. What about
-operating system security?
-</p>
-
-<p>
-On the Internet, you will find a multitude of documents helping you secure your
-system. Some of these documents are procedure-driven (execute this, delete that,
-change permissions of this file and that file) and are often found as security
-best practices for operating systems or distributions. You can find such
-documents on the project sites themselves (such as the <uri
-link="/doc/en/security/security-handbook.xml">Gentoo Security Handbook</uri>) or
-on specialized sites of organizations that keep track of secure configuration
-baselines in general (such as <uri
-link="http://www.cisecurity.org">CISecurity</uri>'s benchmark documents).
-Others are higher-level descriptions (often called frameworks) that help you
-focus on the various fields in which security plays a role.
-</p>
-
-<p>
-A simple example of such higher-level descriptions can be seen in the CoBIT
-framework, which has a process called <e>Ensure Systems Security</e> which
-defines (at least) the following control objectives:
-</p>
-
-<ol>
- <li>Manage Security Measures</li>
- <li>Identification, Authentication and Access</li>
- <li>Security of Online Access to Data</li>
- <li>User Account Management</li>
- <li>Management Review of User Accounts</li>
- <li>User Control of User Accounts</li>
- <li>Security Surveillance</li>
- <li>Data Classification</li>
- <li>Central Identification and Access Rights Management</li>
- <li>Violation and Security Activity Reports</li>
- <li>Incident Handling</li>
- <li>Re-accreditation</li>
- <li>Counterparty Trust</li>
- <li>Transaction Authorization</li>
- <li>Non-repudiation</li>
- <li>Trusted Path</li>
- <li>Protection of Security Functions</li>
- <li>Cryptographic Key Management</li>
- <li>Malicious Software Preventions, Detection and Correction</li>
- <li>Firewall Architectures and Connections with Public Networks</li>
- <li>Protection of Electronic Value</li>
-</ol>
-
-<p>
-If your head is not spinning yet, then I suggest to dive deeper into these
-subjects. However, for this handbook, we'll leave it at this and focus on those
-topics that are relevant for further SELinux discussions.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Operating System Security Best Practices</title>
-<body>
-
-<p>
-To properly secure any operating system, there are a few best practices that you
-might need to keep in mind. They do not cover the full spectrum of configuration
-directives or requirements, but if you do not implement those properly, you risk
-that the threats facing your system become reality faster.
-</p>
-
-<dl>
- <dt>Only run necessary services</dt>
- <dd>
- Only run services (scripts, daemons, jobs, servers ...) of which you know
- you need them. Regularly verify your system runtime behavior to see if no
- services are running that you don't need. The more services that run, the
- more <e>access vectors</e> intruders or malicious people have towards your
- system.
- </dd>
- <dt>Update your system regularly</dt>
- <dd>
- Updating your system will resolve all potential vulnerabilities of software
- you have if they were known by the developers and fixed in later versions.
- Some distributions, including Gentoo, allow you to pull in only
- security-related updates so that your upgrade cycle is not too time and
- resource consuming. See <c>glsa-check</c> for more information on how to do
- this with Gentoo.
- </dd>
- <dt>Do not use privileged accounts</dt>
- <dd>
- For each task you execute on a system, make sure that that task has the
- least amount of privileges needed to get to its goal. Only a few services
- will require root privileges (Unix/Linux' highest privileged account), but
- other accounts might also be seen as privileged (such as accounts that have
- password-less <c>sudo</c> rights, or accounts that are in the <e>wheel</e>
- group. The same is true for your regular day-to-day tasks.
- </dd>
- <dt>Implement a good password policy</dt>
- <dd>
- Make sure that your passwords are not easy to guess or to brute-force. If
- your system uses passwords for authentication and the password is
- compromised, security is completely compromised as well as, as far as the
- system knows, the malicious user that is using your password is you.
- </dd>
- <dt>Configure your services properly</dt>
- <dd>
- Do not trust services to come with a good, default configuration. Most
- default configurations are so that the majority of users can use the service
- (feature-wise), which might not always be the proper configuration for you.
- </dd>
- <dt>Use proper permissions</dt>
- <dd>
- Make sure your files are properly protected permission-wise. Never use
- world-readable files and only allow other accounts to read (or modify) your
- file(s) if they need to. Use group-permissions wisely and often validate
- group membership. If file systems can be used in a read-only fashion, do so.
- If you do not need to access a particular file system by default, don't
- mount it.
- </dd>
-</dl>
-
-<p>
-This is just a subset of best practices. One of the aspects within an operating
-system setup is the method of <e>accessing</e> the system, services or data.
-Implementing a good access control is mandatory from a systems' security
-point-of-view.
-</p>
-
-</body>
-</subsection>
--->
-<subsection>
-<title>Access Control</title>
-<body>
-
-<p>
-A decent access control system (or group of systems) ensures that only
-authorized individuals or processes are granted access to the resources they are
-tring to work with.
-</p>
-
-<p>
-Before one can implement an access control system, you first need to have proper
-authentication in place. If your authentication schemes are flawed, your access
-control system might not be able to differentiate legitimate users from
-malicious ones.
-</p>
-
-<p>
-Authenticating users within Linux is often done through PAM (<e>Pluggable
-Authentication Modules</e>), a powerful mechanism to integrate multiple
-low-level authentication schemes into a high-level interface.
-</p>
-
-<p>
-Authorizing access to resources however is often done through a simple
-permission scheme. Most resources are not hidden by default, although
-patches and updates exist (such as those offered by Gentoo Hardened's
-kernel sources with grSecurity patches which includes support for this
-kind of measures). File-system wise, you can hide the existence of files
-by ensuring the directory in which the file resides is not readable nor
-"executable" by unauthorized accounts.
-</p>
-
-<p>
-This default permission scheme has major drawbacks. It does not allow you to
-define very flexible authorizations (it only allows permissions on three levels:
-owner, group-owner and everybody else) and is limited to read/write/execute
-rights (although a few additional attributes are supported nowadays as well).
-</p>
-
-<p>
-Another drawback is that the permission scheme is <e>discretionary</e>, meaning
-that users and processes are able to change the security policy in place.
-</p>
-
-<p>
-For the majority of uses, this permission scheme is sufficient and has proven to
-offer a decent method for managing access authorizations. But the drawbacks have
-shown to be a major hole in the Linux' offering.
-</p>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>Mandatory Access Control</title>
-<subsection>
-<title>Enter SELinux</title>
-<body>
-
-<p>
-If the above mentioned discretionary access control, abbreviated to <e>DAC</e>,
-is not sufficient (and if you are keen on security, you will not find it
-sufficient), you need a <e>Mandatory</e> Access Control, or <e>MAC</e> system.
-</p>
-
-<p>
-When using a MAC system, activities that a process wants to perform on another
-resource need to be explicitly allowed. It offers a higher granularity on
-permissions as well as resources. They often support not only files, but also
-sockets, ports, memory segments, queues, processes, kernel services, system
-calls, devices, file systems and more. The granularity of activities supported
-is also quite large. For files, this can be append, create, execute, write,
-link, ioctl, get- and setattr, read, rename, lock, ... whereas for sockets this
-might be append, bind, connect, create, write, sendto, accept, ... Also, when
-using a MAC system, no user or process can manipulate the security policy
-itself: what the security administrator has defined cannot be overturned.
-</p>
-
-<p>
-This is where SELinux comes to play. SELinux is a Linux kernel feature which
-implements, amongst other things, a MAC system for controlling and governing
-access to various resources. It uses a deny-by-default permission scheme, so any
-access that a process wants to perform needs to be explicitly granted.
-</p>
-
-<p>
-SELinux also allows you to put a finer-grained permission model <b>on top
-of</b> the traditional DAC system (which is still in use when using SELinux
-- in other words, if the traditional system does not allow certain activities,
-it will not be allowed even if there are SELinux policies granting the
-permission).
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>What is SELinux</title>
-<body>
-
-<p>
-To support this finer-grained permission model, you would think that changes
-are needed to the Linux kernel. Yet thanks to the Linux kernel <e>LSM</e>
-interface (<e>Linux Security Modules</e>), support for SELinux was easily added
-and since the 2.6 kernel series, SELinux has been integrated in the mainstream
-kernel release. But supporting SELinux and using SELinux are very different topics.
-</p>
-
-<p>
-In order to properly identify resources, SELinux needs to assign labels to these
-resources. When the resources are in-memory, this is mostly supported by the
-Linux kernel itself, but for persistent resources such as files, these labels
-need to be placed somewhere. SELinux has chosen to use a file's extended
-attributes (which is stored on the file system itself). The advantage here is
-that a label remains on the file even if the file is renamed. A disadvantage of
-this approach is that the file system must support <e>extended attributes</e>,
-which not all file systems do (or have activated).
-</p>
-
-<p>
-SELinux also uses roles to govern resource access. A user that does not have
-access to the system administration role should never be allowed to execute any
-system administration activities even if he is able to escalate its privileges
-(say through a set-uid application). To support roles, SELinux requires changes
-to the authentication services (PAM) and needs to store role definitions and
-authorizations somewhere.
-</p>
-
-<p>
-Next to the kernel support and labels assigned to the resources and support
-within the authorization system, SELinux also requires particular tools to
-support the SELinux features. Examples are administrative tools to view and
-manipulate labels, privilege management tools (like <c>sudo</c>), system
-services (like SysVInit) etc. This is reflected in a set of patches
-against these (and more) tools which are not always part of the applications'
-main source code.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Gentoo Hardened and SELinux</title>
-<body>
-
-<p>
-What Gentoo Hardened offers is SELinux integrated in the distribution. When you
-select SELinux support, Gentoo Hardened will apply the necessary patches against
-the applications and help you (re)label your files and other resources to become
-SELinux-manageable. Gentoo Hardened also integrates SELinux support inside
-Portage, allowing for newly installed files to be automatically labeled and to
-use a SELinux-supporting sandbox environment for
-safe package building.
-</p>
-
-<p>
-Next to the pure technological support, we hope that you will also find the
-necessary supporting documents, guides, experience and on-line support for using
-SELinux within Gentoo. Never hesitate to come and say hi on the
-<c>#gentoo-hardened</c> chat channel in the Freenode IRC network or on our
-mailing lists.
-</p>
-
-<p>
-If you believe that SELinux is the right thing for you and you want to try it
-out using Gentoo Hardened, please read on. The next chapter will inform you how
-SELinux security is "designed" and how it is conceptually structured. Further
-chapters will then help you with the authorization language and the "base"
-policies that most distributions start from, and finally help you install,
-run and manage a SELinux hardened Gentoo system.
-</p>
-
-</body>
-</subsection>
-</section>
-</sections>
diff --git a/xml/selinux/hb-intro-referencepolicy.xml b/xml/selinux/hb-intro-referencepolicy.xml
deleted file mode 100644
index 566dc00..0000000
--- a/xml/selinux/hb-intro-referencepolicy.xml
+++ /dev/null
@@ -1,255 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-referencepolicy.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>1</version>
-<date>2011-06-02</date>
-
-<section>
-<title>About SELinux Policies</title>
-<subsection>
-<title>SELinux Policy Language</title>
-<body>
-
-<p>
-As described previously, SELinux uses type enforcement to describe the state of
-your system. This is done by giving each resource on your system (be it a
-process, a network port, a file or directory) a specific type and describe the
-rules how types can work with each other.
-</p>
-
-<p>
-For instance, the allow-rule to allow all regular users (which are in the
-user_t domain) to execute files with the bin_t label:
-</p>
-
-<pre caption="Allow rule to execute bin_t files">
-allow user_t bin_t:file { read execute open };
-</pre>
-
-<p>
-Other supported rules are
-</p>
-
-<ul>
- <li>
- <e>dontaudit</e> will disable the logging of the denial message(s)
- </li>
- <li>
- <e>auditallow</e> will allow the access but will also log it (by default,
- allowances are not logged)
- </li>
- <li>
- <e>neverallow</e> forces that a certain allow rule cannot be granted. Even
- though SELinux is a positive security model (white listing), sometimes
- neverallow rules might be needed. But generally you will not often see them.
- </li>
-</ul>
-
-<p>
-As you can imagine, defining the rules for an entire system is very
-resource-intensive if you want to do it right. It not only requires a deep
-insight in how the system works, but also a lot of rule writing and testing. But
-even more time consuming is that you will write the same rules over and over
-again for different domains. To help developers with policy writing, a
-<e>reference policy</e> has been brought to life with the following required
-functionalities:
-</p>
-
-<ul>
- <li>
- development of SELinux policy rules should be centralized even for different
- distributions
- </li>
- <li>
- a macro language should be supported that makes it easier to write new
- policies
- </li>
- <li>
- the policies should be modular, allowing for additional rules to be added or
- removed
- </li>
-</ul>
-
-<p>
-By centralizing the SELinux policy rule development, SELinux users will have the
-same domain naming conventions as on other distributions. This makes debugging a
-lot easier, documenting a lot less distribution-specific and makes it a bit
-easier for end users to get acquainted with SELinux.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Tresys Reference Policy</title>
-<body>
-
-<p>
-The reference policy by choice is the <uri
-link="http://oss.tresys.com/projects/refpolicy">Tresys SELinux Reference
-Policy</uri>. This reference policy - currently at major version 2 - is used by
-almost all SELinux supporting distributions, including Gentoo Hardened, Fedora,
-RedHat Enterprise Linux, Debian, Ubuntu and more. This implementation not only
-offers the modular policies that users are looking for, but also enhances the
-SELinux experience with additional development tools that make it easier to
-work with the SELinux policies on your system.
-</p>
-
-<p>
-The reference policy starts off with a <e>base</e> policy called
-<path>base.pp</path>. This is a collection of policies needed to get a system up
-and running and also offers the necessary functions towards the policy modules.
-In Gentoo Hardened, this base policy is offered by <c>selinux-base-policy</c>.
-</p>
-
-<p>
-The policy modules themselves also use the <path>.pp</path> extension, but are
-named more appropriately towards their content. For instance, the policy module
-that contains all policy rules for the <c>screen</c> application is called
-<path>screen.pp</path>. However, don't count on all policy modules to be named
-after the tool: the policy module that contains the <c>wpa_supplicant</c>
-specific rules is called <path>networkmanager.pp</path>. In Gentoo Hardened, the
-modular policies are available in the <path>sec-policy</path> category and are
-named <path>selinux-<module></path>.
-</p>
-
-<p>
-To get a list of running modules, run <c>semodule</c>:
-</p>
-
-<pre caption="Listing the running SELinux policy modules">
-~# <i>semodule -l</i>
-dbus 1.14.0
-dnsmasq 1.9.0
-hal 1.13.0
-[...]
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Toggle Policy States</title>
-<body>
-
-<p>
-As policies are built off from a "deny all" perspective, you can imagine that
-there are thousands of rules already available in the reference policy.
-Sometimes the developers know that particular rules will be active on one system
-and inactive on another. Although this can be accomplished by developing two
-different modules, SELinux development has opted to support <e>SELinux
-booleans</e>.
-</p>
-
-<p>
-SELinux booleans allow for rules to be conditionally applied, based on the
-administrator's requirements. You can get a list of supported booleans through
-<c>getsebool</c>:
-</p>
-
-<pre caption="Getting a list of supported booleans and their current state">
-~# <i>getsebool -a</i>
-allow_execheap --> off
-allow_execmem --> off
-[...]
-fcron_crond --> off
-global_ssp --> on
-[...]
-</pre>
-
-<p>
-If you need to change a boolean, you can use <c>togglesebool</c> to switch its
-value, or <c>setsebool</c> so explicitly set its state:
-</p>
-
-<pre caption="Toggling boolean states">
-~# <i>getsebool user_dmesg</i>
-user_dmesg --> off
-~# <i>togglesebool user_dmesg</i>
-user_dmesg: active
-<comment>(Now, the state is set to 'on')</comment>
-~# <i>getsebool user_dmesg</i>
-user_dmesg --> on
-<comment>(Explicitly set the value to 'off')</comment>
-~# <i>setsebool user_dmesg off</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Policy Files and Locations</title>
-<body>
-
-<p>
-On Gentoo Hardened, the SELinux policy files are stored in
-<path>/usr/share/selinux/strict</path> or
-<path>/usr/share/selinux/targeted</path> (depending on your SELinux
-configuration). Within this location, you will find:
-</p>
-
-<ul>
- <li>
- a file called <path>base.pp</path>, which is the SELinux base policy,
- </li>
- <li>
- one or more files with extension <path>.pp</path>, which are the SELinux
- policy modules, and
- </li>
- <li>
- an <path>include/</path> folder which contains the necessary files for
- SELinux module developers to build additional modules for this system
- </li>
-</ul>
-
-</body>
-</subsection>
-<subsection>
-<title>Policy Versions</title>
-<body>
-
-<p>
-The SELinux policy infrastructure that is used (i.e. the capabilities and
-functionalities that it offers) isn't in its first version. If you would run
-<c>sestatus</c> now, you'll notice that we are using policy version 24. Every
-time functionalities or capabilities are added which require changes to the
-internal structure of the compiled policy, this version is incremented. The
-following is an overview of the policy versions' history.
-</p>
-
-<dl>
- <dt>Version 12</dt>
- <dd>"Old API" for SELinux, which is now deprecated</dd>
- <dt>Version 15</dt>
- <dd>"New API" for SELinux, merged in Linux kernel 2.6.0 (until 2.6.5)</dd>
- <dt>Version 16</dt>
- <dd>Conditional policy extensions added (2.6.5)</dd>
- <dt>Version 17</dt>
- <dd>IPV6 support added (2.6.6 - 2.6.7)</dd>
- <dt>Version 18</dt>
- <dd>Fine-grained netlink socket support added (2.6.8 - 2.6.11)</dd>
- <dt>Version 19</dt>
- <dd>Enhanced multi-level security (2.6.12 - 2.6.13)</dd>
- <dt>Version 20</dt>
- <dd>Access vector table size optimizations (2.6.14 - 2.6.18)</dd>
- <dt>Version 21</dt>
- <dd>Object classes in range transitions (2.6.19 - 2.6.24)</dd>
- <dt>Version 22</dt>
- <dd>Policy capabilities (features) (2.6.25)</dd>
- <dt>Version 23</dt>
- <dd>Per-domain permissive mode (2.6.26 - 2.6.27)</dd>
- <dt>Version 24</dt>
- <dd>Explicit hierarchy (type bounds) (2.6.28 - 2.6.38)</dd>
- <dt>Version 25</dt>
- <dd>Filename based transition support (2.6.39)</dd>
- <dt>Version 26</dt>
- <dd>Role transition support for non-process classes (3.0)</dd>
-</dl>
-
-</body>
-</subsection>
-</section>
-</sections>
diff --git a/xml/selinux/hb-intro-resources.xml b/xml/selinux/hb-intro-resources.xml
deleted file mode 100644
index 488d72b..0000000
--- a/xml/selinux/hb-intro-resources.xml
+++ /dev/null
@@ -1,111 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-reference.xml,v 1.4 2011/06/09 17:37:45 klondike Exp $ -->
-
-<sections>
-<version>2</version>
-<date>2011-05-31</date>
-
-<section>
-<title>Background</title>
-<subsection>
-<title>Introduction to SELinux</title>
-<body>
-
-<ul>
- <li>
- <uri link="http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml">The Inevitability of Failure:
- The Flawed Assumption of Security in Modern Computing Environments</uri>
- explains the need for mandatory access controls.
- </li>
- <li>
- <uri link="http://www.nsa.gov/research/_files/selinux/papers/flask-abs.shtml">The Flask Security Architecture:
- System Support for Diverse Security Policies</uri>
- explains the security architecture of Flask, the architecture used by SELinux.
- </li>
- <li>
- <uri link="http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml">Implementing SELinux as a Linux Security Module</uri>
- has specifics about SELinux access checks in the kernel.
- </li>
-</ul>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>SELinux Policy</title>
-<subsection>
-<title>Policy Related References</title>
-<body>
-
-<ul>
- <li>
- <uri link="http://www.nsa.gov/research/_files/selinux/papers/policy2-abs.shtml">Configuring the SELinux Policy</uri>
- </li>
- <li>
- <uri link="http://oss.tresys.com/projects/refpolicy">SELinux Reference Policy</uri>
- </li>
- <li>
- SELinux <uri link="http://www.selinuxproject.org/page/ObjectClassesPerms">Object Classes and Permissions</uri> Overview
- </li>
-</ul>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>Books</title>
-<subsection>
-<title>Paper Books</title>
-<body>
-
-<ul>
- <li>
- <c>SELinux by Example: Using Security Enhanced Linux</c>, Frank Mayer,
- Karl MacMillan, and David Caplan, Prentice Hall, 2006; ISBN 0131963694
- </li>
- <li>
- <c>SELinux: NSA's Open Source Security Enhanced Linux</c>, Bill McCarty,
- O'Reilly Media, 2004; ISBN 0596007167
- </li>
-</ul>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Gentoo Specific Resources</title>
-<subsection>
-<title>Gentoo Hardened</title>
-<body>
-
-<p>
-The following resources are specific towards Gentoo Hardened's SELinux
-implementation.
-</p>
-
-<ul>
- <li>
- <uri link="/proj/en/hardened/selinux-faq.xml">SELinux Frequently Asked
- Questions</uri>
- </li>
- <!--
- <li>
- <uri link="/proj/en/hardened/selinux-development.xml">SELinux Development
- Guidelines</uri>
- </li>
- <li>
- <uri link="/proj/en/hardened/selinux-policy.xml">SELinux Policy</uri>
- </li>
- -->
-</ul>
-
-</body>
-</subsection>
-</section>
-</sections>
diff --git a/xml/selinux/hb-intro-virtualization.xml b/xml/selinux/hb-intro-virtualization.xml
deleted file mode 100644
index cf082e0..0000000
--- a/xml/selinux/hb-intro-virtualization.xml
+++ /dev/null
@@ -1,25 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-intro-virtualization.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
-
-<sections>
-<version>0</version>
-<date>2010-12-01</date>
-
-<section>
-<title>TODO</title>
-<subsection>
-<body>
-
-<p>
-This is a place-holder for future expansion.
-</p>
-
-</body>
-</subsection>
-</section>
-</sections>
diff --git a/xml/selinux/hb-using-commands.xml b/xml/selinux/hb-using-commands.xml
deleted file mode 100644
index ae55d83..0000000
--- a/xml/selinux/hb-using-commands.xml
+++ /dev/null
@@ -1,492 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-commands.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>6</version>
-<date>2011-10-15</date>
-
-<section>
-<title>SELinux Information Commands</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-You should currently have a SELinux enabled system (but running in permissive
-mode, so it will not enforce its policy rules). So before we introduce you to
-the world of SELinux and how you can add more rules to make sure your system
-remains functional when you switch to enforcing mode, we first give a quick
-overview of the various SELinux related commands.
-</p>
-
-<p>
-We start off with state commands where you can get global information on SELinux
-state (is it running in enforcing mode or not, versions etc.)
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Getting SELinux Status</title>
-<body>
-
-<p>
-The first command we will talk about is <c>sestatus</c>.
-</p>
-
-<pre caption="Running sestatus">
-# <i>sestatus</i>
-SELinux status: enabled
-SELinuxfs mount: /selinux
-Current mode: permissive
-Mode from config file: permissive
-Policy version: 24
-Policy from config file: strict
-</pre>
-
-<p>
-The output of this command shows you that SELinux is enabled and is currently in
-the <e>permissive</e> mode. It also tells you that the system is configured to
-run in <e>strict</e> mode - so no unconfined_t domain here.
-</p>
-
-<p>
-The <c>sestatus</c> command also has an extended output if you run it with the
-<c>-v</c> option. When this is done, the command returns the contexts of
-important processes and files:
-</p>
-
-<pre caption="Running sestatus -v">
-# <i>sestatus -v</i>
-SELinux status: enabled
-SELinuxfs mount: /selinux
-Current mode: enforcing
-Mode from config file: enforcing
-Policy version: 24
-Policy from config file: strict
-
-Process contexts:
-Current context: staff_u:sysadm_r:sysadm_t
-Init context: system_u:system_r:init_t
-/sbin/agetty system_u:system_r:getty_t
-/usr/sbin/sshd system_u:system_r:sshd_t
-
-File contexts:
-Controlling term: staff_u:object_r:user_devpts_t
-/sbin/init system_u:object_r:init_exec_t
-/sbin/agetty system_u:object_r:getty_exec_t
-/bin/login system_u:object_r:login_exec_t
-/sbin/rc system_u:object_r:rc_exec_t
-/usr/sbin/sshd system_u:object_r:sshd_exec_t
-/sbin/unix_chkpwd system_u:object_r:chkpwd_exec_t
-/etc/passwd system_u:object_r:etc_t
-/etc/shadow system_u:object_r:shadow_t
-/bin/sh system_u:object_r:bin_t -> system_u:object_r:shell_exec_t
-/bin/bash system_u:object_r:shell_exec_t
-/usr/bin/newrole system_u:object_r:newrole_exec_t
-/lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:lib_t
-/lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld_so_t
-</pre>
-
-<p>
-Another general SELinux status command is <c>getenforce</c>, which allows you to
-quickly see if your SELinux is running in enforcing mode (SELinux policies are
-enforced), permissive (SELinux policies are checked and logged, but not
-enforced) or disabled (SELinux policy is not loaded and thus not checked).
-</p>
-
-<pre caption="Using the getenforce command">
-# <i>getenforce</i>
-Enforcing
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Getting SELinux Object Information</title>
-<body>
-
-<p>
-Next on the table is the <c>seinfo</c> command. This command allows you to query
-the running policy for all objects (types, roles, attributes, users, booleans
-...) defined.
-</p>
-
-<p>
-Common usages are:
-</p>
-
-<ul>
- <li>
- checking if a specific domain is defined on your system (in case you're
- wondering if you need to load an additional SELinux policy module or not)
- </li>
- <li>
- checking which domains a particular role can be in (in case you're wondering
- if your regular users are allowed by SELinux policies to even be
- transitioned towards a specific domain)
- </li>
- <li>
- checking which attributes are assigned to a specific domain (or vice versa,
- which domains have a specific attribute set) as some SELinux policy rules
- work on attributes rather than domains
- </li>
-</ul>
-
-<p>
-As an example, we query if the crontab_t domain is known, if the user_r role can
-use the contab_t domain and finally which domains have the cron_spool_type
-attribute set.
-</p>
-
-<pre caption="Using seinfo">
-# <i>seinfo -tcrontab_t</i>
- crontab_t
-# <i>seinfo -ruser_r -x</i>
- user_r
- Dominated Roles:
- user_r
- Types:
- [...]
- crontab_t
- [...]
-# <i>seinfo -acron_spool_type -x</i>
- cron_spool_type
- user_cron_spool_t
- system_cron_spool_t
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Querying SELinux Policy Rules</title>
-<body>
-
-<p>
-A command which you will often use is <c>sesearch</c>. This command allows you
-to query the current policy allow rules and is a huge help when trying to find
-out if something is allowed (or why something isn't allowed).
-</p>
-
-<p>
-The <c>sesearch</c> command is most often used with a source domain (<c>-s</c>),
-target domain (<c>-t</c>) or both, the class for which you want to query allow
-rules for (file, dir, socket, process ...) and the privilege you want to query
-for (read, write, open, transition, execute ...).
-</p>
-
-<p>
-For instance, to find out which domains can write the files that have the
-shadow_t domain:
-</p>
-
-<pre caption="Querying allow rules with sesearch">
-# <i>sesearch -t shadow_t -c file -p write -A</i>
-Found 8 semantic av rules:
- [...]
- allow portage_t shadow_t : file { ioctl read write ... };
- allow useradd_t shadow_t : file { ioctl read write ... };
- ...
-</pre>
-
-<p>
-You will notice that there are sometimes results based on attributes rather than
-domains:
-</p>
-
-<pre caption="Allow rule based on attribute">
- allow portage_t file_type : file { ioctl read write ... };
-</pre>
-
-<p>
-In this case, the source domain (portage_t) is allowed to write to files whose
-domain have the file_type attribute set. If you get the feeling of these things,
-you'll wonder if the above rule is not a flagrant security issue as almost all
-domains for files have the file_type set. Yes and no - if we take a look at
-which domains have file write privileges to file_type domains, you'll notice
-that this is only portage:
-</p>
-
-<pre caption="Querying domains with file-write privileges to file_type domains">
-# <i>sesearch -t file_type -c file -p write -A -d</i>
-Found 1 semantic av rules:
- allow portage_t file_type : file { ioctl read write ... };
-</pre>
-
-<p>
-Note that we had one command without the <c>-d</c> option and one with. When
-<c>-d</c> is given, the search will perform an exact search without resolving
-the attributes. When <c>-d</c> is not given, it will resolve the attribute. In
-the last command example, dropping <c>-d</c> would result in hundreds of allow
-rules: for each domain that has file_type set, the search tries to find rules
-that allow file-write access to that particular domain.
-</p>
-
-<p>
-Another interesting functionality of the <c>sesearch</c> command is to show you
-the rules that are applicable depending on the state of a boolean. If you want
-to query on a particular boolean, use <c>-b</c>. If you want to see the logic
-that the policy uses, use <c>-C</c> (and yes, both can be combined).
-</p>
-
-<p>
-As an example, we'll check what we allow (or deny) when the <c>global_ssp</c>
-boolean is set:
-</p>
-
-<pre caption="Checking the policy regarding the global_ssp boolean">
-# <i>sesearch -b global_ssp -A -C -d</i>
-Found 2 semantic av rules:
-ET allow domain device_t : dir { getattr search open } ; [ global_ssp ]
-ET allow domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ global_ssp ]
-</pre>
-
-<p>
-The prefix you see shows two letters, relating to two important definitions:
-</p>
-
-<ul>
- <li>
- Is the rule currently <b>E</b>nabled or <b>D</b>isabled?
- </li>
- <li>
- Does the boolean need to be set to <b>T</b>rue or <b>F</b>alse to enable the rule?
- </li>
-</ul>
-
-</body>
-</subsection>
-<subsection>
-<title>Getting Security Context Information</title>
-<body>
-
-<p>
-During administrative tasks, and especially when you are checking if a SELinux
-denial could be made, it is important to find out what the security context is
-for a particular resource. Luckily, Gentoo Hardened - if properly installed -
-has already patched some tools to allow you to get this information using your
-standard tools.
-</p>
-
-<p>
-To get the security context of a file, use <c>ls -Z</c>:
-</p>
-
-<pre caption="Getting a file security context">
-~$ <i>ls -Z /etc/make.conf</i>
-system_u:object_r:portage_conf_t /etc/make.conf
-</pre>
-
-<p>
-To get the security context of a process, use <c>ps -Z</c>:
-</p>
-
-<pre caption="Getting a process security context">
-# <i>ps -Z $(pidof init)</i>
-LABEL PID TTY STAT TIME COMMAND
-system_u:system_r:init_t 1 ? Ss 0:00 init [3]
-</pre>
-
-<p>
-To get the security context of the current user, use <c>id -Z</c>:
-</p>
-
-<pre caption="Getting a user security context">
-~$ <i>id -Z</i>
-staff_u:staff_r:staff_t
-</pre>
-
-</body>
-</subsection>
-</section>
-<section>
-<title>Managing SELinux</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-Managing SELinux objects (booleans, users, ports, contexts ...) is most often
-done using <c>semanage</c>. As this application offers the interface towards
-various SELinux configurations, we dedicate an entire section on it, but will
-also cover the commands that offer similar functionality (and are sometimes
-easier to remember).
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Booleans</title>
-<body>
-
-<p>
-We have already covered SELinux booleans earlier in this book as well as the
-<c>getsebool</c> and <c>setsebool</c> commands. With <c>semanage</c> you can too
-manage the booleans and, as an added bonus, listing the booleans will also show
-the description of the boolean (even though there is still work to be done in
-this area).
-</p>
-
-<pre caption="Listing the available SELinux booleans">
-# <i>semanage boolean -l</i>
-SELinux boolean Description
-
-allow_ptrace -> off allow_ptrace
-rsync_export_all_ro -> off rsync_export_all_ro
-</pre>
-
-<note>
-As you will notice, most descriptions are just the boolean name, but you will
-find more and more booleans with a better description as you get acquainted with
-- and install more - SELinux policy modules.
-</note>
-
-<p>
-You can set a boolean with both <c>setsebool</c> and <c>semanage</c>:
-</p>
-
-<pre caption="Setting SELinux boolean values">
-# <i>semanage boolean -m --on -F user_dmesg</i>
-</pre>
-
-</body>
-</subsection>
-<subsection id="users">
-<title>SELinux Users and Logins</title>
-<body>
-
-<p>
-SELinux users and logins are different from Unix accounts. SELinux logins allow
-you to map a Unix account to a SELinux user:
-</p>
-
-<pre caption="Listing the SELinux logins">
-# <i>semanage login -l</i>
-Login Name SELinux User
-
-__default__ user_u
-root root
-swift staff_u
-system_u system_u
-</pre>
-
-<p>
-The default behavior is that users are logged on as the <e>user_u</e> SELinux
-user. This SELinux user is a non-administrator user: it has no specific
-privileges and should be used for every account that never requires elevated
-privileges (so no <c>su</c> or <c>sudo</c> rights for anything).
-</p>
-
-<p>
-The account you use to administer your system should be mapped to the
-<c>staff_u</c> SELinux user (or its own user with the appropriate roles). This
-can be accomplished as follows (example with the Unix account <e>anna</e>):
-</p>
-
-<pre caption="Letting 'anna' log on as 'staff_u'">
-# <i>semanage login -a -s staff_u anna</i>
-</pre>
-
-<impo>
-Make sure that whatever account you use to administer your system is mapped to
-the <c>staff_u</c> user, or has the ability to switch to the <c>sysadm_r</c>
-role. Portage only works from within the <c>sysadm_r</c> role.
-</impo>
-
-<p>
-As mentioned, SELinux users are configured to be able to join in on one or more
-roles. To list the available roles, you can use <c>semanage user -l</c>:
-</p>
-
-<pre caption="Listing login / role mappings">
-# <i>semanage user -l</i>
-SELinux User SELinux Roles
-
-root staff_r sysadm_r
-staff_u staff_r sysadm_r
-[...]
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Managing Ports</title>
-<body>
-
-<p>
-Even network ports (like port 22 for SSH) are 'protected' by SELinux. To get an
-overview of which domains are assigned to which ports (or port ranges) use
-<c>semanage port -l</c>.
-</p>
-
-<pre caption="Listing SELinux managed ports">
-# <i>semanage port -l | grep '22$'</i>
-ssh_port_t tcp 22
-</pre>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Using SELinux</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-Up until now we've covered getting SELinux related information as well as
-managing SELinux settings. However, users on a SELinux hardened system will also
-need to know a few things about working with SELinux, including (but not limited
-to) roles and role transitions.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Switching Roles</title>
-<body>
-
-<p>
-As a type enforcement access control system, SELinux allows particular roles to
-be within a set of domains. If you are using a role which is not allowed within
-a particular domain, you will not be successful in using that domain and will be
-denied the actions assigned to that domain.
-</p>
-
-<p>
-If your standard users are all SELinux user_u users (with the only supported
-role being user_r) then those users will never need to switch roles (nor are
-they allowed to). But users that are staff_u (or other users that have multiple
-roles) those users should be made clear how they switch between roles. We have
-already covered how to map such users to the correct SELinux user (see <uri
-link="#users">SELinux Users and Logins</uri>).
-</p>
-
-<p>
-The command that accomplishes switching roles is called <c>newrole</c>. It's
-use is pretty straight forward.
-</p>
-
-<pre caption="Using newrole">
-~$ <i>newrole -r sysadm_r</i>
-Password: <comment>(Enter the users' password - not root's!)</comment>
-</pre>
-
-<p>
-When performing a role transition, SELinux will ask the user to re-authenticate
-through its users' password. If you are logged on as a regular user and used
-<c>su</c> or <c>sudo</c> to become the root user, then <c>newrole</c> will still
-require you to enter the regular users' password.
-</p>
-
-</body>
-</subsection>
-</section>
-
-</sections>
diff --git a/xml/selinux/hb-using-configuring.xml b/xml/selinux/hb-using-configuring.xml
deleted file mode 100644
index 8a87b54..0000000
--- a/xml/selinux/hb-using-configuring.xml
+++ /dev/null
@@ -1,981 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-permissive.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>1</version>
-<date>2011-09-30</date>
-
-<section>
-<title>Administering Users</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-During the installation, we already covered how to map a Linux user to a SELinux
-user. In the example, we used a hypothetical user "john" and mapped him to the
-SELinux user "staff_u". If you are running a multi-user system, managing the
-right mappings is important. A user that is mapped to the SELinux user "user_u"
-will not get any additional rights. Even if you would give that user additional
-rights through commands such as <c>sudo</c>, the SELinux policy will not allow
-this user to do anything that is administration related.
-</p>
-
-<p>
-For this reason, it is important to go over the SELinux user mappings and the
-Linux users on your system.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>User Mappings</title>
-<body>
-
-<p>
-Run <c>semanage login -l</c> to show the current mappings between Linux logins
-and SELinux users.
-</p>
-
-<pre caption="Running semanage login -l">
-# <i>semanage login -l</i>
-
-Login Name SELinux User
-
-__default__ user_u
-root root
-john staff_u
-system_u system_u
-</pre>
-
-<p>
-The "user_u" SELinux user is for regular accounts. As such, the special
-<e>__default__</e> mapping is defined by SELinux to denote every login that is
-not defined otherwise. This makes sure that a newly defined account does not get
-elevated privileges by default.
-</p>
-
-<p>
-The next table gives an overview of the standard SELinux users available after
-an installation.
-</p>
-
-<table>
-<tr>
- <th>SELinux User</th>
- <th>Description</th>
-</tr>
-<tr>
- <ti>user_u</ti>
- <ti>
- Default regular SELinux user, which should be used by end-user accounts that
- are not going to administer any service(s) on the system
- </ti>
-</tr>
-<tr>
- <ti>staff_u</ti>
- <ti>
- SELinux user for administrators. This user has the right to switch roles and
- as such gain elevated privileges
- </ti>
-</tr>
-<tr>
- <ti>root</ti>
- <ti>
- SELinux user for the root account. It differs little from the staff_u
- account beyond being a different ID. This ensures that files protected by
- the user based access control for root cannot be handled by the staff_u
- (and other) users
- </ti>
-</tr>
-<tr>
- <ti>sysadm_u</ti>
- <ti>
- SELinux user for system administration. By default, this account is not
- immediately used as this user immediately gets the administrative role
- (whereas staff_u and root still need to switch roles).
- </ti>
-</tr>
-<tr>
- <ti>system_u</ti>
- <ti>
- SELinux user for system services. It should never be used for end users or
- administrators as it provides direct access to the system role (and
- privileges)
- </ti>
-</tr>
-<tr>
- <ti>unconfined_u</ti>
- <ti>
- Used when the policy is <e>targeted</e>, this SELinux user has many
- privileges (it is essentially not limited in its actions, although it is
- still handled through SELinux - just through a "wide open" policy).
- </ti>
-</tr>
-</table>
-
-<p>
-To map a user to a specific SELinux user, use <c>semanage login -a</c>:
-</p>
-
-<pre caption="Mapping a user 'sophie' to the staff_u user">
-# <i>semanage login -a -s staff_u sophie</i>
-</pre>
-
-<p>
-However, when you update such mapping, the files in that users' home directory
-will be owned by a wrong SELinux user. It is therefor important to relabel the
-files of that user:
-</p>
-
-<pre caption="Relabeling sophie's files">
-# <i>restorecon -R -F /home/sophie</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Additional SELinux Accounts</title>
-<body>
-
-<p>
-It is perfectly possible to create additional SELinux accounts, and then map the
-Linux logins to these new accounts. This can be necessary when you want a more
-thorough auditing (on end user level) or when you will be enhancing the policy
-with additional roles. Also, if you want to use the User Based Access Control
-feature, using different SELinux users is important to enforce the control on
-different users (if they all use the same SELinux user, then UBAC has little to
-no effect).
-</p>
-
-<p>
-Managing the SELinux accounts is done through <c>semanage user</c>:
-</p>
-
-<pre caption="Creating a SELinux user">
-# <i>semanage user -a -R "staff_r sysadm_r" sophie</i>
-</pre>
-
-<p>
-Let's verify how the SELinux users are currently configured:
-</p>
-
-<pre caption="Checking the SELinux user identities">
-# <i>semanage user -l</i>
-SELinux User SELinux Roles
-
-root staff_r sysadm_r
-sophie staff_r sysadm_r
-staff_u staff_r sysadm_r
-sysadm_u sysadm_r
-system_u system_r
-unconfined_u unconfined_r
-user_u user_r
-
-# <i>semanage login -l</i>
-Login Name SELinux User
-
-__default__ user_u
-root root
-sophie staff_u
-swift staff_u
-system_u system_u
-</pre>
-
-<p>
-Now that a new SELinux user called "sophie" exists, we can now update the Linux
-user mapping for "sophie" towards the new SELinux user "sophie":
-</p>
-
-<pre caption="Updating the Linux user mapping">
-# <i>semanage login -m -s sophie sophie</i>
-# <i>semanage login -l</i>
-Login Name SELinux User
-
-__default__ user_u
-root root
-sophie sophie
-swift staff_u
-system_u system_u
-</pre>
-
-<p>
-Again, do not forget to relabel this users' files.
-</p>
-
-<p>
-As you can see, managing SELinux users means defining the roles to which the
-user has access to. We already gave a high-level introduction to the default
-roles in <uri link="?part=1&chap=2">SELinux Concepts</uri>, but as roles are
-important when using a Mandatory Access Control system, let's refresh our memory
-again:
-</p>
-
-<table>
-<tr>
- <th>SELinux Role</th>
- <th>Description</th>
-</tr>
-<tr>
- <ti>user_r</ti>
- <ti>
- Default end-user role. This role provides access to regular applications and
- activities, but does not allow any system or service administration beyond
- what is expected for a regular user.
- </ti>
-</tr>
-<tr>
- <ti>staff_r</ti>
- <ti>
- Default administration role for day-to-day activities. This role has some
- additional privileges beyond what is offered through user_r, but is not a
- full system administrative role. It is meant for the non-administrative
- activities done by operators and administrators
- </ti>
-</tr>
-<tr>
- <ti>sysadm_r</ti>
- <ti>
- System administration role. This role is highly privileged (since it also
- contains the privileges to update the policy) and should only be given to
- fully trusted administrators. It is almost never immediately granted to
- users (they first need to switch roles) except for direct root access (for
- instance through the console)
- </ti>
-</tr>
-<tr>
- <ti>system_r</ti>
- <ti>
- System service role, which is used for the runtime services (processes). It
- is never granted to users directly.
- </ti>
-</tr>
-<tr>
- <ti>unconfined_r</ti>
- <ti>
- The unconfined role is used when the <e>targeted</e> policy is supported.
- This role is given to unconfined users (such as the SELinux unconfined_u
- user) which have very wide privileges (they almost run without constraints).
- </ti>
-</tr>
-</table>
-
-<p>
-It should be noted that these roles are the default ones, but the security
-administrator - yes, that means you - can create additional roles and add
-particular privileges to it. We will discuss this later in this book as it means
-you'll need to update the Gentoo Hardened SELinux policy.
-</p>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Reading Audit Logs</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-When working with a SELinux-enabled system, you will eventually notice that
-things behave differently, but without giving any meaningful error message.
-Usually, when SELinux "denies" a particular access, it logs it into the audit
-log of the system, but for the application itself, it is perfectly possible that
-it just silently dies. If not, you're most likely to get a <e>permission
-denied</e> error message.
-</p>
-
-<p>
-Initially, SELinux is running in <c>permissive</c> mode, which means that
-SELinux will log what it <e>would</e> deny, but still let it through.
-This mode is perfect for getting the system in shape without having too
-much problems keeping it running. Once you think your security settings are
-in order, then this mode can be switched from <c>permissive</c> to
-<c>enforcing</c>. We'll talk about these modes later.
-</p>
-
-<p>
-First, let's take a look at the audit log and see what it is saying...
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Audit Log Location(s)</title>
-<body>
-
-<p>
-The SELinux kernel code writes its denials (and sometimes even allowed but
-audited activities) into the audit log. If you are running on a Gentoo Hardened
-installation with the <c>syslog-ng</c> system logger, then the logger is already
-configured to place these audit lines in <path>/var/log/avc.log</path>. However,
-different system loggers or system logger configurations might put the entries
-in a different log location (such as <path>/var/log/audit.log</path>).
-</p>
-
-<p>
-Below, you'll find the appropriate lines for the syslog-ng system logger
-configuration for writing the events in <path>/var/log/avc.log</path>.
-</p>
-
-<pre caption="syslog-ng.conf excerpt for SELinux AVC entries">
-<comment># The following lines are only /part/ of the configuration file!</comment>
-source kernsrc { file("/proc/kmsg"); };
-destination avc { file("/var/log/avc.log"); };
-filter f_avc { message(".*avc: .*"); };
-
-log {
- source(kernsrc);
- filter(f_avc);
- destination(avc);
-};
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>What is AVC?</title>
-<body>
-
-<p>
-As we mentioned, SELinux writes its entries in the audit log. These entries are
-called <e>avc messages</e> or <e>avc log entries</e>. The abbreviation AVC
-stands for <e>Access Vector Cache</e> and, like the name sais, is a caching
-system.
-</p>
-
-<p>
-Using an access vector cache improves performance on dealing with (and
-enforcing) activities and privileges. Since SELinux offers a very detailed
-approach on privileges and permissions, it would become quite painful
-(performance-wise) if each call means that the SELinux code needs to look up the
-domain, the target resource label, the privilege and if it is allowed or not
-over and over again. Instead, SELinux uses the Access Vector Cache to store past
-requests/responses. It is the AVC subsystem that is responsible for checking
-accesses and (if necessary) logging it.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Reading an AVC Denial Message</title>
-<body>
-
-<p>
-Below you'll find a typical AVC denial message.
-</p>
-
-<pre caption="Example AVC denial message">
-Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
- avc: denied { module_request } for pid=14561 comm="firefox" kmod="net-pf-10"
- scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system
-</pre>
-
-<p>
-Let's analyze each part of this message one by one.
-</p>
-
-<pre caption="AVC denial: Timestamp and location information">
-<i>Oct 15 13:04:54 hpl kernel: [963185.177043]</i> type=1400 audit(1318676694.660:2472):
- avc: denied { module_request } for pid=14561 comm="firefox" kmod="net-pf-10"
- scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t tclass=system
-</pre>
-
-<p>
-This first part of the message informs you when the message was written (Oct 15
-13:04:54), on which host (hpl) and how many seconds since the system was booted
-(963185.177043).
-</p>
-
-<pre caption="AVC denial: source information">
-Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
- avc: denied { module_request } for <i>pid=14561 comm="firefox"</i> kmod="net-pf-10"
- <i>scontext=staff_u:staff_r:mozilla_t</i> tcontext=system_u:system_r:kernel_t tclass=system
-</pre>
-
-<p>
-Next is the source of the denial, i.e. what process is trying to do something.
-In this case, the process is firefox, with PID 14561, which is running in the
-source domain staff_u:staff_r:mozilla_t.
-</p>
-
-<pre caption="AVC denial: target resource">
-Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
- avc: denied { module_request } for pid=14561 comm="firefox" <i>kmod="net-pf-10"</i>
- scontext=staff_u:staff_r:mozilla_t <i>tcontext=system_u:system_r:kernel_t</i> tclass=system
-</pre>
-
-<p>
-The target of the activity is a kernel module (net-pf-10, which is the internal
-name given for IPv6), labeled system_u:system_r:kernel_t
-</p>
-
-<pre caption="AVC denial: denied action">
-Oct 15 13:04:54 hpl kernel: [963185.177043] type=1400 audit(1318676694.660:2472):
- avc: denied { <i>module_request</i> } for pid=14561 comm="firefox" kmod="net-pf-10"
- scontext=staff_u:staff_r:mozilla_t tcontext=system_u:system_r:kernel_t <i>tclass=system</i>
-</pre>
-
-<p>
-Finally, the action that is denied (module_request) and its class (system).
-These classes help you to identify what is denied, because a read on a file is
-different from a read on a directory.
-</p>
-
-<p>
-For instance, in the following case, a process <c>gorg</c> with PID 13935 is
-trying to read a file called <path>localtime</path> with inode 130867 which
-resides on the device <path>/dev/md3</path>:
-</p>
-
-<pre caption="AVC denial example">
-Oct 15 14:40:30 hpl kernel: [968909.807802] type=1400 audit(1318682430.323:2614):
- avc: denied { read } for pid=13935 comm="gorg" name="localtime" dev=md3 ino=130867
- scontext=staff_u:sysadm_r:gorg_t tcontext=system_u:object_r:locale_t tclass=file
-</pre>
-
-<p>
-In this case, it might be obvious that the file is <path>/etc/localtime</path>,
-but when that isn't the case, then you can find the following two commands
-useful:
-</p>
-
-<pre caption="Finding out the target resource based on inode and device">
-<comment>(Find out which device /dev/md3 is)</comment>
-# <i>mount | grep /dev/md3</i>
-/dev/md3 on / type ext4 (rw,seclabel,noatime,barrier=1,nodelalloc,data=journal)
-
-<comment>(Find out what file has inode 130867)</comment>
-# <i>find / -xdev -inum 130867</i>
-/etc/localtime
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Handling AVC denials</title>
-<body>
-
-<p>
-The major part of configuring SELinux is reading the denials, finding out what
-needs to be fixed (or ignored), fix it, and repeat the steps. Hopefully, the
-rest of this handbook will help you figure out what is causing a denial.
-</p>
-
-<p>
-Denials can be cosmetic (an activity that is denied, but has no effect on the
-application's functional behaviour). If that is the case, the denial can be
-marked as <e>dontaudit</e>, meaning that the denial is not logged by default
-anymore. If you think that a denial is occurring but you do not see it in the
-logs, try disabling the <e>dontaudit</e> rules:
-</p>
-
-<pre caption="Disabling dontaudit">
-<comment>(The command can also be abbreviated to "semodule -DB")</comment>
-# <i>semodule --build --disable_dontaudit</i>
-</pre>
-
-<p>
-In most cases though, denials need to be acted upon. Actions that might need to
-happen are:
-</p>
-
-<ul>
- <li>
- relabeling the target resource (wrong labels might cause legitimate actions
- to be denied)
- </li>
- <li>
- relabeling the source (process' binary file) as a wrong label might cause
- the application to run in the wrong domain
- </li>
- <li>
- loading a necessary SELinux module, since the modules contain the rules to
- allow (and label) resources. Without the appropriate module loaded, you will
- notice denials since no other module gives the necessary grants (allow
- statements)
- </li>
- <li>
- granting the right role to the user executing the application. We have
- covered users and their roles initially but we will go deeper into this
- subject later in the handbook.
- </li>
- <li>
- adding your own SELinux policy statements, most likely because no SELinux
- policy module exists for the application you are trying to run
- </li>
-</ul>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Using (File) Labels</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-Within SELinux, access privileges are based on the label given on the
-originating part (called the <e>domain</e>) and its target resource. For
-instance, a process running in the passwd_t domain wants to read (= privilege)
-the file <path>/etc/shadow</path> which is labeled shadow_t (= the target
-resource). It comes to no surprise then that the majority of SELinux
-administration is (re)labeling the resources correctly (and ensuring their label
-stays correct).
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Getting File Label(s)</title>
-<body>
-
-<p>
-There are many ways to relabel commands, and none of them are equal to another.
-But before we explain this in more detail, let's first take a look at a few file
-labels (and how you can query them).
-</p>
-
-<p>
-In SELinux, labels are given on a file level through the file systems' ability
-to keep <e>extended attributes</e>. For SELinux, the attribute is called
-<c>security.selinux</c> and can be obtained through <c>getfattr</c>:
-</p>
-
-<pre caption="Getting a file's extended attribute for SELinux">
-$ <i>getfattr -n security.selinux /etc/hosts</i>
-# file: etc/hosts
-security.selinux="system_u:object_r:net_conf_t"
-</pre>
-
-<p>
-Of course, getting the file attribute this way is time consuming and not that
-flexible. For this purpose, most important applications (including
-<c>coreutils</c>) are made SELinux-aware. These applications mostly use the
-<c>-Z</c> option to display the SELinux context information. In case of files,
-this means the extended attribute content:
-</p>
-
-<pre caption="Getting the context of a file">
-$ <i>ls -Z /etc/hosts</i>
-system_u:object_r:net_conf_t /etc/hosts
-</pre>
-
-<p>
-Other commands exist that display the context as it should be, like
-<c>matchpathcon</c>. However, their purpose is to query the SELinux policy on
-your system to find out what the policy ought to be, not what it is:
-</p>
-
-<pre caption="Difference between context and matchpathcon result">
-$ <i>ls -Z /etc/make.conf</i>
-staff_u:object_r:etc_t /etc/make.conf
-$ <i>matchpathcon /etc/make.conf</i>
-/etc/make.conf system_u:object_r:portage_conf_t
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Setting File Label(s)</title>
-<body>
-
-<p>
-Now how can you manipulate file labels? Well, first of all: you will not be
-allowed to change the file labels of any possible file (not even if you are the
-owner of that file) unless the SELinux policy allows you to. These allow rules
-are made on two privilege types: which labels are you allowed to change
-(<c>relabelfrom</c>) and to which labels are you allowed to change
-(<c>relabelto</c>). You can query these rules through <c>sesearch</c>:
-</p>
-
-<pre caption="Querying the relabelto/relabelfrom types">
-<comment># From which label on files (-c) is user_t (-s) allowed (-A) to relabel from (-p)?</comment>
-$ <i>sesearch -s user_t -c file -p relabelfrom -A</i>
-<comment>[...]</comment>
-allow user_t mozilla_home_t : file { <comment>...</comment> relabelfrom relabelto } ;
-</pre>
-
-<p>
-If you have the permission, then you can use <c>chcon</c> to <e>ch</e>ange the
-<e>con</e>text of a file:
-</p>
-
-<pre caption="Changing a file context">
-$ <i>ls -Z strace.log</i>
-staff_u:object_r:user_home_t strace.log
-$ <i>chcon -t mutt_home_t strace.log</i>
-$ <i>ls -Z strace.log</i>
-staff_u:object_r:mutt_home_t strace.log
-</pre>
-
-<p>
-If you do not hold the right privileges, you will get a descriptive error
-message:
-</p>
-
-<pre caption="Trying to change file context">
-$ <i>chcon -t shadow_t strace.log</i>
-chcon: failed to change context of `strace.log' to `staff_u:object_r:shadow_t': Permission denied
-</pre>
-
-<p>
-Now, if you now think that <c>chcon</c> is all you need, you're wrong. The
-<c>chcon</c> command does nothing more than what it sais - change context. But
-when the system relabels files, these changes are gone. Relabeling files is
-often done to ensure that the file labels are correct (as in: the labels match
-what the SELinux policy sais they ought to be). The SELinux policy contains, for
-each policy module, the list of files, directories, sockets, ... and their
-appropriate file context (label).
-</p>
-
-<p>
-We will look at SELinux policy modules later, but below you'll find an excerpt
-from such a definition, for the <c>mozilla</c> module:
-</p>
-
-<pre caption="Excerpt of the mozilla module file contexts">
-/usr/bin/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0)
-/usr/bin/mozilla-[0-9].* -- gen_context(system_u:object_r:mozilla_exec_t,s0)
-/usr/bin/mozilla-bin-[0-9].* -- gen_context(system_u:object_r:mozilla_exec_t,s0)
-/usr/lib(64)?/galeon/galeon -- gen_context(system_u:object_r:mozilla_exec_t,s0)
-/usr/lib(64)?/netscape/.+/communicator/communicator-smotif\.real -- gen_context(system_u:object_r:mozilla_exec_t,s0)
-/usr/lib(64)?/netscape/base-4/wrapper -- gen_context(system_u:object_r:mozilla_exec_t,s0)
-/usr/lib/[^/]*firefox[^/]*/plugin-container -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0)
-/usr/lib64/[^/]*firefox[^/]*/plugin-container -- gen_context(system_u:object_r:mozilla_plugin_exec_t,s0)
-</pre>
-
-<p>
-To put the right label on a file, you can use the <c>setfiles</c> or
-<c>restorecon</c> commands. Since they are both the same command (but with a
-slightly different way of using) we'll only talk about <c>restorecon</c> for now
-- more information on the <c>setfiles</c> command can be found in its man page.
-</p>
-
-<p>
-When you use <c>restorecon</c>, the application will query the SELinux policy to
-find out what the right label of the file should be. If it differs, it will
-change the label to the right setting. That means that you do not need to
-provide the label for a file in order for the command to work. Also,
-<c>restorecon</c> supports recursivity, so you do not need to relabel files one
-by one.
-</p>
-
-<pre caption="Using restorecon">
-$ <i>ls -Z /etc/make.conf</i>
-staff_u:object_r:etc_t /etc/make.conf
-$ <i>restorecon /etc/make.conf</i>
-$ <i>ls -Z /etc/make.conf</i>
-system_u:object_r:portage_conf_t /etc/make.conf
-</pre>
-
-<p>
-Finally, Gentoo also provides a useful application: <c>rlpkg</c>. This script
-relabels the files of a Gentoo package (<c>rlpkg <packagename></c>) or,
-given the right arguments, all files on the file system:
-</p>
-
-<pre caption="Using rlpkg">
-<comment># Relabel the files of the firefox-bin package:</comment>
-# <i>rlpkg firefox</i>
-
-<comment># Relabel all files on the file system:</comment>
-# <i>rlpkg -a -r</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Overriding the SELinux Policy File Labels</title>
-<body>
-
-<p>
-You might not always agree with the label that the SELinux policy enforces on
-the files: you might have your files located elsewhere (a different location for
-your Portage tree is a nice example) or you need to label them differently in
-order for other applications to work. To not have to <c>chcon</c> these files
-over and over again, you can enhance the SELinux policy on your system with
-additional file context rules. These rules are used when you call
-<c>restorecon</c> as well and override the rules provided by the SELinux policy.
-</p>
-
-<p>
-To add additional file context rules, you need to use the <c>semanage</c>
-command. This command is used to manage, manipulate and update the local SELinux
-policy on your system. In this particular case, we will use the <c>semanage
-fcontext</c> command:
-</p>
-
-<pre caption="Using semanage to add a file context rule">
-<comment># Mark /mnt/gentoo/etc/make.conf as a portage_conf_t type</comment>
-# <i>semanage fcontext -a -t portage_conf_t /mnt/gentoo/etc/make.conf</i>
-
-<comment># Mark /mnt/gentoo/usr/portage as portage_ebuild_t</comment>
-# <i>semanage fcontext -a -t portage_ebuild_t "/mnt/gentoo/usr/portage(/.*)?"</i>
-</pre>
-
-<p>
-As you can see from the example, you can use wildcards. But beware about using
-wildcards: when a rule holds a wildcard, it has a lower priority than a rule
-without a wildcard. And the priority on rules with a wildcard is based on how
-"down" the string the first occurance of a wildcard is. For more information,
-please check out our <uri link="../selinux-faq.xml#matchcontext">FAQ on "How do
-I know which file context rule is used for a particular file?."</uri>
-</p>
-
-<p>
-If you want to delete a file context definition, you use <c>semanage fcontext
--d</c>:
-</p>
-
-<pre caption="Deleting a file context definition">
-# <i>semanage fcontext -d -t portage_ebuild_t /mnt/gentoo/etc/make.conf</i>
-</pre>
-
-<p>
-Finally, to view all file context definitions (both user-set and SELinux policy
-provided), you can use <c>semanage fcontext -l</c>. To only see the locally set,
-add <c>-C</c>:
-</p>
-
-<pre caption="Viewing user-set file context enhancements">
-# <i>semanage fcontext -C -l</i>
-SELinux fcontext type Context
-/opt/xxe/bin/.*\.jar all files system_u:object_r:lib_t
-/srv/virt/gentoo(/.*)? all files system_u:object_r:qemu_image_t
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Customizable types</title>
-<body>
-
-<p>
-Labels on files are not that hard to understand, but you might come into some
-surprises if you do not know that there are also customizable types.
-</p>
-
-<p>
-A <e>customizable type</e> is a specific type which is not touched by the
-SELinux administration tools by default. If you want to relabel a file that
-currently holds a customizable type, you will need to force this through the
-commands (such as <c>restorecon -F</c>).
-</p>
-
-<p>
-There are not that many customizable types by default. The list of types that
-SELinux considers as customizable are mentioned in the
-<path>customizable_types</path> file within the
-<path>/etc/selinux/*/contexts</path> location:
-</p>
-
-<pre caption="Listing the customizable types">
-# <i>cat /etc/selinux/strict/contexts/customizable_types</i>
-mount_loopback_t
-public_content_rw_t
-public_content_t
-swapfile_t
-textrel_shlib_t
-</pre>
-
-<p>
-Such types exist because these types are used for files whose location is known
-not to be fixed (and as such, the SELinux policy cannot without a doubt know if
-the label on the files is correct or not). The <c>public_content_t</c> one,
-which is used for files that are readable by several services (like FTP, web
-server, ...), might give you a nice example for such a case.
-</p>
-
-<p>
-If you look at the <c>restorecon</c> man page, it mentions both customizable
-types as well as the user section. The latter is for rules that are identified
-in the SELinux policy as being files for an end user, like the following
-definitions in the <c>mozilla</c> policy module:
-</p>
-
-<pre caption="User section definition within mozilla module">
-HOME_DIR/\.mozilla(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0)
-HOME_DIR/\.netscape(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0)
-HOME_DIR/\.phoenix(/.*)? gen_context(system_u:object_r:mozilla_home_t,s0)
-</pre>
-
-<p>
-Although in the above example, forcing <c>restorecon</c> on the files is
-probably correct, there are examples where you do not want this. For instance,
-the firefox policy by default only allows the application to write to
-directories labeled <c>mozilla_home_t</c>. If you want to download something,
-this isn't possible (unless you download it into <path>~/.mozilla</path>). The
-solution there is to label a directory (say <path>~/Downloads</path>) as
-<c>mozilla_home_t</c>.
-</p>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>SELinux Policy and Booleans</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-We have dealt with users and labels now, but there is still a third aspect that
-we haven't touched: the SELinux policy itself.
-</p>
-
-<p>
-The SELinux policy as offered by Gentoo Hardened is a carefully tuned SELinux
-policy, based on the reference policy (a distribution-agnostic SELinux policy)
-with minor changes. Hopefully, you will not need to rewrite the policy to suit
-it for your needs, but changes are very likely to occur here and there.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Changing the SELinux Policy Behavior: Booleans</title>
-<body>
-
-<p>
-A common and user friendly way of tweaking the SELinux policy is through
-booleans. A <e>SELinux boolean</e>, also known as a conditional, changes how the
-SELinux policy behaves based on the setting that the user provides. To make this
-a bit more clear, let's look at a few booleans available:
-</p>
-
-<pre caption="Getting SELinux booleans">
-# <i>getsebool -a | grep ^user</i>
-user_direct_mouse --> off
-user_dmesg --> off
-user_ping --> on
-user_rw_noexattrfile --> off
-user_tcp_server --> off
-user_ttyfile_stat --> off
-</pre>
-
-<p>
-Although they might not say much on first sight, these booleans alter how the
-SELinux policy enforces user activity (hence the booleans starting with
-<path>user_</path>). For instance, <c>user_ping</c> is set to <c>on</c>, so a
-user is allowed to use <c>ping</c>. If it was set to <c>off</c>, the SELinux
-policy would not allow a user to execute <c>ping</c>.
-</p>
-
-<p>
-Booleans can be toggled on or off using <c>setsebool</c> or <c>togglesebool</c>.
-With <c>setsebool</c> you need to give the value (on or off) whereas
-<c>togglesebool</c> switches the value.
-</p>
-
-<pre caption="Disallowing the use of ping by users">
-# <i>setsebool user_ping off</i>
-</pre>
-
-<p>
-By default, <c>setsebool</c> does not store the boolean values - after a reboot,
-the old values are used again. To persist such changes, you need to add the
-<c>-P</c> option:
-</p>
-
-<pre caption="Persistedly allow users to run dmesg">
-# <i>setsebool -P user_dmesg on</i>
-</pre>
-
-<p>
-Booleans allow administrators to tune the policy, and allow security
-administrators to write policies that are flexible enough for a more widespread
-use. In terms of Gentoo flexibility, these booleans might not be used enough (it
-would be nice to couple these booleans on USE flags, so that a server build with
-USE="ldap" gets the SELinux policy to use ldap, whereas USE="-ldap" disallows
-it). But still, the use of booleans is a popular method for making a more
-flexible SELinux policy.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Managing SELinux Policy Modules</title>
-<body>
-
-<p>
-In this last part, we'll cover SELinux policy modules. We mentioned before that
-the SELinux policy used by Gentoo Hardened is based on the reference policy,
-which offers a modular approach to SELinux policies. There is one base policy,
-which is mandatory on every system and is kept as small as possible. The rest
-are SELinux policy modules, usually providing the declarations, rules and file
-contexts for a single application (or type of applications).
-</p>
-
-<p>
-With <c>semodule -l</c> you can see the list of SELinux policy modules loaded:
-</p>
-
-<pre caption="Listing the loaded SELinux modules">
-# <i>semodule -l</i>
-alsa 1.11.0
-apache 2.3.0
-entropyd 1.6.0
-dbus 1.15.0
-dnsmasq 1.9.0
-<comment>(...)</comment>
-</pre>
-
-<p>
-Within Gentoo Hardened, each module is provided by the package
-<path>sec-policy/selinux-<modulename></path>. For instance, the first
-module encountered in the above example is provided by
-<path>selinux-alsa</path>:
-</p>
-
-<pre caption="The SELinux policy module package in Gentoo">
-$ <i>emerge --search selinux-alsa</i>
-Searching...
-[ Results for search key : selinux-alsa ]
-[ Applications found : 1]
-
-* sec-policy/selinux-alsa
- Latest version available: 2.20110726
- Latest version installed: 2.20110726
- Size of files: 574 kB
- Homepage: http://www.gentoo.org/proj/en/hardened/selinux/
- Description: SELinux policy for alsa
- License: GPL-2
-</pre>
-
-<p>
-If you need a module that isn't installed on your system, this is considered a
-bug (packages that need it should depend on the SELinux policy package if the
-selinux USE flag is set). But once you install the package yourself, the module
-will be loaded automatically:
-</p>
-
-<pre caption="Installing a SELinux policy package">
-# <i>emerge selinux-screen</i>
-</pre>
-
-<p>
-If you want to remove a module from your system though, uninstalling the package
-will not suffice: the SELinux policy module itself is copied to the policy store
-earlier (as part of the installation process) and is not removed from this store
-by Portage. Instead, you will need to remove the module manually:
-</p>
-
-<pre caption="Uninstalling a SELinux policy module">
-# <i>emerge -C selinux-screen</i>
-# <i>semodule -r screen</i>
-</pre>
-
-</body>
-</subsection>
-</section>
-</sections>
diff --git a/xml/selinux/hb-using-install.xml b/xml/selinux/hb-using-install.xml
deleted file mode 100644
index 672f11d..0000000
--- a/xml/selinux/hb-using-install.xml
+++ /dev/null
@@ -1,741 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-install.xml,v 1.4 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>24</version>
-<date>2012-05-07</date>
-
-<section>
-<title>Installing Gentoo (Hardened)</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-Getting a SELinux-powered Gentoo installation doesn't require weird actions.
-What you need to do is install Gentoo Linux with the correct profile, correct
-kernel configuration and some file system relabelling. We seriously recommend to
-use SELinux together with other hardening improvements (such as PaX /
-grSecurity).
-</p>
-
-<p>
-This chapter will describe the steps to install Gentoo with SELinux. We
-assume that you have an existing Gentoo Linux system which you want to convert
-to Gentoo with SELinux. If this is not the case, you should still read
-on: you can install Gentoo with SELinux immediately if you make the
-correct decisions during the installation process, based on the information in
-this chapter.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Performing a Standard Installation</title>
-<body>
-
-<p>
-Install Gentoo Linux according to the <uri link="/doc/en/handbook">Gentoo
-Handbook</uri> installation instructions. We recommend the use of the hardened
-stage 3 tarballs and <c>hardened-sources</c> kernel instead of the standard
-ones, but standard stage installations are also supported for SELinux.
-Perform a full installation to the point that you have booted your system
-into a (primitive) Gentoo base installation.
-</p>
-
-<note>
-If you are an XFS user, make sure that the inode sizes of the XFS file
-system is 512 byte. Since the default is 256, you will need to run the
-<c>mkfs.xfs</c> command with the <c>-i size=512</c> arguments, like so:
-<c>mkfs.xfs -i size=512 /dev/sda3</c>
-</note>
-
-</body>
-</subsection>
-<!--
-<subsection>
-<title>Installing the Hardened Development Overlay</title>
-<body>
-
-<p>
-Although optional, we recommend to enable the <c>hardened-development</c>
-overlay. The state of SELinux within Gentoo Hardened is still undergoing
-major development.
-</p>
-
-<p>
-Install <c>app-portage/layman</c> and add the <c>hardened-development</c>
-overlay. This overlay uses a git repository, so either install <c>git</c> as
-well, or set <c>USE="git"</c> in <path>/etc/make.conf</path>.
-Make sure to include layman's <path>make.conf</path> in your
-<path>make.conf</path> file.
-</p>
-
-<pre caption="Installing hardened-development overlay">
-~# <i>emerge layman</i>
-
-~# <i>layman -S</i>
-
-~# <i>layman -a hardened-development</i>
-
-~# <i>nano /etc/make.conf</i>
-<comment># Add the following line at the top of your make.conf file</comment>
-<i>source /var/lib/layman/make.conf</i>
-</pre>
-
-</body>
-</subsection>
--->
-<!--
-TODO Validate after 2.20120215-r8 is stable that this is no longer
-necessary? Not sure about it though : check userspace ebuilds as well.
--->
-<subsection>
-<title>Switching to Python 2</title>
-<body>
-
-<p>
-For now, the SELinux management utilities are not compatible with Python 3 so
-we recommend to switch to Python 2 until the packages are updated and fixed.
-</p>
-
-<pre caption="Switching to python 2">
-~# <i>emerge '<=dev-lang/python-3.0'</i>
-~# <i>eselect python list</i>
-Available Python interpreters:
- [1] python2.7
- [2] python3.1 *
-
-~# <i>eselect python set 1</i>
-~# <i>source /etc/profile</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Optional: Setting the filesystem contexts</title>
-<body>
-
-<p>
-If your <path>/tmp</path> location is a tmpfs-mounted file system, then you need
-to tell the kernel that the root context of this location is <c>tmp_t</c>
-instead of <c>tmpfs_t</c>. Many SELinux policy objects (including various
-server-level policies) assume that <path>/tmp</path> is <c>tmp_t</c>.
-</p>
-
-<p>
-To configure the <path>/tmp</path> mount, edit your <path>/etc/fstab</path>:
-</p>
-
-<pre caption="Update /etc/fstab for /tmp">
-<comment># For a "targeted" or "strict" policy type:</comment>
-tmpfs /tmp tmpfs defaults,noexec,nosuid<i>,rootcontext=system_u:object_r:tmp_t</i> 0 0
-
-<comment># For an "mls" or "mcs" policy type:</comment>
-tmpfs /tmp tmpfs defaults,noexec,nosuid<i>,rootcontext=system_u:object_r:tmp_t:s0</i> 0 0
-</pre>
-
-</body>
-</subsection>
-<!--
-<subsection>
-<title>Enabling ~Arch Packages</title>
-<body>
-
-<p>
-The current stable SELinux related packages are not fit for use anymore (or are
-even broken) so we seriously recommend to enable ~arch packages for SELinux. Add
-the following settings to the right file (for instance
-<path>/etc/portage/package.accept_keywords/selinux</path>):
-</p>
-
-<pre caption="SELinux ~arch packages">
-=sys-process/vixie-cron-4.1-r11
-</pre>
-
-</body>
-</subsection>
--->
-<subsection>
-<title>Change the Gentoo Profile</title>
-<body>
-
-<p>
-Now that you have a running Gentoo Linux installation, switch the Gentoo profile
-to the right SELinux profile (for instance,
-<path>hardened/linux/amd64/no-multilib/selinux</path>). Note that the older
-profiles (like <path>selinux/v2refpolicy/amd64/hardened</path>) are not
-supported anymore.
-</p>
-
-<pre caption="Switching the Gentoo profile">
-~# <i>eselect profile list</i>
-Available profile symlink targets:
- [1] default/linux/amd64/10.0
- [2] default/linux/amd64/10.0/selinux
- [3] default/linux/amd64/10.0/desktop
- [4] default/linux/amd64/10.0/desktop/gnome
- [5] default/linux/amd64/10.0/desktop/kde
- [6] default/linux/amd64/10.0/developer
- [7] default/linux/amd64/10.0/no-multilib
- [8] default/linux/amd64/10.0/server
- [9] hardened/linux/amd64
- [10] hardened/linux/amd64/selinux
- [11] hardened/linux/amd64/no-multilib *
- [12] hardened/linux/amd64/no-multilib/selinux
-
-~# <i>eselect profile set 12</i>
-</pre>
-
-<note>
-Starting from the profile change, Portage will warn you after every installation
-that it was "Unable to set SELinux security labels". This is to be expected,
-because the tools and capabilities that Portage requires to set the security
-labels aren't available yet. This warning will vanish the moment the SELinux
-installation is completed.
-</note>
-
-<p>
-Don't update your system yet - we will need to install a couple of packages in a
-particular order which Portage isn't aware of in the next couple of sections.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Update make.conf</title>
-<body>
-
-<p>
-Next, take a look at the following USE flags and decide if you want to enable
-or disable them.
-</p>
-
-<table>
-<tr>
- <th>USE flag</th>
- <th>Default Value</th>
- <th>Description</th>
-</tr>
-<tr>
- <ti>peer_perms</ti>
- <ti>Enabled</ti>
- <ti>
- The peer_perms capability controls the SELinux policy network peer controls.
- If set, the access control mechanisms that SELinux uses for network based
- labelling are consolidated. This setting is recommended as the policy is
- also updated to reflect this. If not set, the old mechanisms (NetLabel and
- Labeled IPsec) are used side by side.
- </ti>
-</tr>
-<tr>
- <ti>open_perms</ti>
- <ti>Enabled</ti>
- <ti>
- The open_perms capability enables the SELinux permission "open" for files
- and file-related classes. Support for the "open" call was added a bit later
- than others so support was first made optional. However, the policies have
- matured sufficiently to have the open permission set.
- </ti>
-</tr>
-<tr>
- <ti>ubac</ti>
- <ti>Enabled</ti>
- <ti>
- When disabled, the SELinux policy is built without user-based access control.
- </ti>
-</tr>
-</table>
-
-<p>
-Make your choice and update the <c>USE</c> variable in
-<path>/etc/make.conf</path>.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Manual System Changes</title>
-<body>
-
-<warn>
-Most, if not all of the next few changes will be resolved through regular
-packages as soon as possible. However, these fixes have impact beyond the Gentoo
-Hardened installations. As such, these changes will be incorporated a bit slower
-than the SELinux-specific updates. For the time being, manually correcting these
-situations is sufficient (and a one-time operation).
-</warn>
-
-<p>
-The following changes <e>might</e> be necessary on your system, depending on the
-tools or configurations that apply.
-</p>
-
-<ul>
- <li>
- Check if you have <path>*.old</path> files in <path>/bin</path>. If you do,
- either remove those or make them a copy of their counterpart so that they
- get their own security context. The <path>.old</path> files are hard links
- which mess up the file labelling. For instance, <c>cp /bin/hostname
- /bin/hostname.old</c>.
- </li>
- <!--
- TODO When portage fix is stabilized, convert docs to /sys/fs/selinux
- -->
- <li>
- Edit <path>/etc/sandbox.conf</path> and add in
- <c>SANDBOX_WRITE="/sys/fs/selinux/context"</c>. This is temporarily needed
- until the necessary fix (included in Portage but not stable yet) is
- available.
- </li>
-</ul>
-
-</body>
-</subsection>
-<subsection>
-<title>Installing a SELinux Kernel</title>
-<body>
-
-<p>
-Although the default Linux kernels offer SELinux support, we recommend the use
-of the <path>sys-kernel/hardened-sources</path> package.
-</p>
-
-<pre caption="Installing hardened-sources">
-<comment>(Only if you have not installed it previously of course)</comment>
-~# <i>emerge hardened-sources</i>
-</pre>
-
-<p>
-Next, reconfigure the kernel with the appropriate security settings. This
-includes, but is not limited to
-</p>
-
-<ul>
- <li>Support for extended attributes in the various file systems</li>
- <li>Support system-call auditing</li>
- <li>Support for SELinux</li>
-</ul>
-
-<p>
-Below you can find a quick overview of the recommended settings.
-</p>
-
-<pre caption="Recommended settings for the Linux kernel configuration">
-<comment>Under "General setup"</comment>
-[*] Prompt for development and/or incomplete code/drivers
-[*] Auditing support
-[*] Enable system-call auditing support
-
-<comment>Under "File systems"</comment>
-<comment>(For each file system you use, make sure extended attribute support is enabled)</comment>
-<*> Second extended fs support
-[*] Ext2 extended attributes
-[ ] Ext2 POSIX Access Control Lists
-[*] Ext2 Security Labels
-[ ] Ext2 execute in place support
-
-<*> Ext3 journalling file system support
-[ ] Default to 'data=ordered' in ext3
-[*] Ext3 extended attributes
-[ ] Ext3 POSIX Access Control Lists
-[*] Ext3 Security Labels
-
-<*> The Extended 4 (ext4) filesystem
-[*] Ext4 extended attributes
-[ ] Ext4 POSIX Access Control Lists
-[*] Ext4 Security Labels
-
-<*> JFS filesystem support
-[ ] JFS POSIX Access Control Lists
-[*] JFS Security Labels
-[ ] JFS debugging
-[ ] JFS statistics
-
-<*> XFS filesystem support
-[ ] XFS Quota support
-[ ] XFS POSIX ACL support
-[ ] XFS Realtime subvolume support (EXPERIMENTAL)
-[ ] XFS Debugging Support
-
-<*> Btrfs filesystem (EXPERIMENTAL)
-[ ] Btrfs POSIX Access Control Lists
-
-<comment>Under "Security options"</comment>
-[*] Enable different security models
-[*] Socket and Networking Security Hooks
-[*] NSA SELinux Support
-[ ] NSA SELinux boot parameter
-[ ] NSA SELinux runtime disable
-[*] NSA SELinux Development Support
-[ ] NSA SELinux AVC Statistics
-(1) NSA SELinux checkreqprot default value
-[ ] NSA SELinux maximum supported policy format version
- Default security module (SELinux) --->
-</pre>
-
-<p>
-We recommend to use PaX as well. More information on PaX within Gentoo Hardened
-can be found in the <uri link="/proj/en/hardened/pax-quickstart.xml">Hardened
-Gentoo PaX Quickstart Guide</uri>.
-</p>
-
-<p>
-Build and install the new Linux kernel and its modules.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Update fstab</title>
-<body>
-
-<p>
-Next, edit <path>/etc/fstab</path> and add the following two lines:
-</p>
-
-<pre caption="Enabling selinux-specific file system options">
-<comment># The udev mount is due to bug #373381</comment>
-udev /dev tmpfs rw,rootcontext=system_u:object_r:device_t,seclabel,nosuid,relatime,size=10m,mode=755 0 0
-none /selinux selinuxfs defaults 0 0
-</pre>
-
-<note>
-In case of an MLS/MCS policy, you need to have the context with sensitivity
-level, so <c>...:device_t:s0</c>.
-</note>
-
-</body>
-</subsection>
-<subsection>
-<title>Reboot</title>
-<body>
-
-<p>
-With the above changes made, reboot your system. Assert yourself that you are
-now running a Linux kernel with SELinux enabled (the <path>/selinux</path> file
-system should be mounted). Don't worry - SELinux is at this point not activated.
-</p>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Configure SELinux</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-Next we will need to configure SELinux by installing the appropriate
-utilities, label our file system and configure the policy.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Install Policies and Utilities</title>
-<body>
-
-<p>
-First, install the <path>sys-apps/checkpolicy</path> and
-<path>sys-apps/policycoreutils</path> packages. Although these will be pulled in
-as dependencies of the SELinux policy packages themselves, we need to install
-these one time first - hence the <c>-1</c> option.
-</p>
-
-<pre caption="Installing SELinux policy core utilities">
-~# <i>emerge -1 checkpolicy policycoreutils</i>
-</pre>
-
-<p>
-Next, install the SELinux policy package
-(<path>sec-policy/selinux-base-policy</path>). This package contains the base
-SELinux policy needed to get your system up and running using SELinux.
-As Portage will try to label and reload policies (since the installation of
-<path>sys-apps/policycoreutils</path>) we need to temporarily disable SELinux
-support (as Portage wouldn't be able to label anything as it doesn't understand
-it yet).
-</p>
-
-<pre caption="Installing the SELinux policy packages">
-~# <i>FEATURES="-selinux" emerge selinux-base-policy</i>
-</pre>
-
-<p>
-Next, rebuild those packages affected by the profile change we did previously
-through a standard world update, taking into account USE-flag changes (as the
-new profile will change many default USE flags, including enabling the
-<c>selinux</c> USE flag). Don't forget to use <c>etc-update</c> or
-<c>dispatch-conf</c> afterwards as some changes to configuration files need to
-be made.
-</p>
-
-<pre caption="Update your Gentoo Linux system">
-~# <i>emerge -uDN world</i>
-</pre>
-
-<p>
-Next, install the additional SELinux tools that you might need in the future to
-debug or help with your SELinux installation. These packages are optional, but
-recommended.
-</p>
-
-<pre caption="Installing additional SELinux packages">
-~# <i>emerge setools sepolgen checkpolicy</i>
-</pre>
-
-<p>
-Finally, install the policy modules for those utilities you think you need
-policies for. In the near future, this will be done automatically for you (the
-packages will have an optional dependency on it, triggered by the selinux USE
-flag), but until that time, you will need to install them yourself.
-</p>
-
-<pre caption="Installing SELinux modules">
-~# <i>emerge --search selinux-</i>
-[...]
-<comment>(Select the modules you want to install)</comment>
-~# <i>emerge selinux-screen selinux-gnupg selinux-sudo selinux-ntp selinux-networkmanager ...</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Configure the SELinux Policy</title>
-<body>
-
-<p>
-Inside <path>/etc/selinux/config</path> you can configure how SELinux is
-configured at boot time.
-</p>
-
-<pre caption="Editing the /etc/selinux/config file">
-# This file controls the state of SELinux on the system on boot.
-
-# SELINUX can take one of these three values:
-# enforcing - SELinux security policy is enforced.
-# permissive - SELinux prints warnings instead of enforcing.
-# disabled - No SELinux policy is loaded.
-SELINUX=<i>permissive</i>
-
-# SELINUXTYPE can take one of these four values:
-# targeted - Only targeted network daemons are protected.
-# strict - Full SELinux protection.
-# mls - Full SELinux protection with Multi-Level Security
-# mcs - Full SELinux protection with Multi-Category Security
-# (mls, but only one sensitivity level)
-SELINUXTYPE=<i>strict</i>
-</pre>
-
-<p>
-Within this configuration file, two variables can be set:
-</p>
-
-<ul>
- <li>
- <c>SELINUX</c> sets how SELinux should behave:
- <ul>
- <li>
- <c>enforcing</c> will enable and enforce policies. This is where we want
- to go for, but you should probably start with <c>permissive</c>.
- </li>
- <li>
- <c>permissive</c> will enable policies, but not enforce them. Any
- violation is reported but not denied. This is where you should start
- from as it will not impact your system yet allow you to get acquainted
- with SELinux - and validate the warnings to see if you can switch
- towards <c>enforcing</c> or not.
- </li>
- <li>
- <c>disabled</c> will completely disable the policies. As this will not
- show any violations as well, it is not recommended.
- </li>
- </ul>
- </li>
- <li>
- <c>SELINUXTYPE</c> selects the SELinux policy type to load.
- Gentoo Hardened recommends the use of <c>strict</c> for servers, and
- <c>targeted</c> for desktops. The <c>mcs</c> type is supported, <c>mls</c>
- is currently still considered experimental.
- </li>
-</ul>
-
-<p>
-The differentiation between <c>strict</c> and <c>targeted</c> is based upon the
-<e>unconfined</e> domain. When loaded, the processes on your system that are not
-specifically confined within a particular policy module will be part of the
-unconfined_t domain whose purpose is to allow most activities by default (rather
-than deny by default). As a result, processes that run inside the unconfined_t
-domain have no restrictions apart from those already enforced by standard Linux
-security. Although running without the unconfined_t domain is considered more
-secure, it will also be more challenging for the administrator to make sure the
-system still functions properly as there are no policy modules for each and
-every application "out there".
-</p>
-
-<p>
-Next to <c>targeted</c> and <c>strict</c>, you can opt for <c>mcs</c> to allow
-categorization of the process domains. This is useful on multi-tenant systems
-such as web servers, virtualization hosts, ... where multiple processes will be
-running, most of them in the same security domain, but in different categories.
-</p>
-
-<p>
-Finally, you can also select <c>mls</c> to differentiate security domains on
-a sensitivity level. However, MLS is currently still considered experimental
-in Gentoo and as such not recommended.
-</p>
-
-<p>
-When you have made your choice between the SELinux policy types, save
-this in your <path>/etc/make.conf</path> file as well. That way, Portage will
-only install the policy modules for that SELinux type.
-</p>
-
-<pre caption="Setting the policy type in make.conf">
-~# <i>nano /etc/make.conf</i>
-POLICY_TYPES="<i>strict</i>"
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Reboot, and Label the File System</title>
-<body>
-
-<impo>
-Repeat these steps every time you have rebooted from a non-SELinux enabled
-kernel into a SELinux enabled kernel, as running with a non-SELinux enabled
-kernel will not update the security attributes of the files you create or
-manipulate during your day-to-day activities on your system.
-</impo>
-
-<p>
-First reboot your system so that the installed policies are loaded. Now we
-need to relabel your devices and openrc related files. This will apply the
-correct security contexts (labels) onto the necessary files.
-</p>
-
-<pre caption="Relabel /dev structure">
-~# <i>mkdir /mnt/gentoo</i>
-~# <i>mount -o bind / /mnt/gentoo</i>
-
-<comment>(Substitute the "strict" in the next command with "targeted" if that is your SELINUXTYPE selection)</comment>
-~# <i>setfiles -r /mnt/gentoo /etc/selinux/strict/contexts/files/file_contexts /mnt/gentoo/dev</i>
-~# <i>setfiles -r /mnt/gentoo /etc/selinux/strict/contexts/files/file_contexts /mnt/gentoo/lib64</i>
-~# <i>umount /mnt/gentoo</i>
-</pre>
-
-<p>
-Next, if you have a swapfile rather than a swap partition, label it accordingly:
-</p>
-
-<pre caption="Labelling the swap file">
-~# <i>semanage fcontext -a -t swapfile_t "/swapfile"</i>
-~# <i>restorecon /swapfile</i>
-</pre>
-
-<p>
-Now relabel your entire file system. The next command will apply the correct
-security context onto the files on your file system, based on the security
-context information provided by the SELinux policy modules installed.
-</p>
-
-<pre caption="Relabel the entire file system">
-~# <i>rlpkg -a -r</i>
-</pre>
-
-<p>
-If you ever have to install a SELinux policy module for a package after that
-that particular package is installed, you need to run <c>rlpkg</c> for that
-package to make sure that the security contexts for these files are set
-correctly. For instance, if you have installed
-<path>sec-policy/selinux-screen</path> after discovering that you have
-<c>screen</c> on your system:
-</p>
-
-<pre caption="Relabeling the files for a single package">
-<comment>(Make sure no screen sessions are running as their security contexts will not be adapted)</comment>
-~# <i>rlpkg -t screen</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Reboot and Set SELinux Booleans</title>
-<body>
-
-<p>
-Reboot your system so that the newly applied file contexts are used. Log on
-and, if you have indeed installed Gentoo using the hardened sources (as we
-recommended), enable the SSP SELinux boolean, allowing every domain read
-access to the <path>/dev/urandom</path> device:
-</p>
-
-<pre caption="Enabling the global_ssp boolean">
-~# <i>setsebool -P global_ssp on</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Define the Administrator Accounts</title>
-<body>
-
-<p>
-If the <c>SELINUXTYPE</c> is set to <c>strict</c>, then we
-need to map the account(s) you use to manage your system (those
-that need access to Portage) to the <c>staff_u</c> SELinux user. If not, none
-of your accounts will be able to succesfully manage the system (except for
-<c>root</c>, but then you will need to login as <c>root</c> directly and not
-through <c>sudo</c> or <c>su</c>.) By default, users are mapped to the
-<c>user_u</c> SELinux user who doesn't have the appropriate rights (nor access
-to the appropriate roles) to manage a system. Accounts that are mapped to
-<c>staff_u</c> can, but might need to switch roles from <c>staff_r</c> to
-<c>sysadm_r</c> before they are granted the appropriate privileges.
-</p>
-
-<p>
-Assuming that your account name is <e>john</e>:
-</p>
-
-<pre caption="Mapping the Linux account john to the SELinux user staff_u">
-~# <i>semanage login -a -s staff_u john</i>
-~# <i>restorecon -R -F /home/john</i>
-</pre>
-
-<p>
-If you later log on as <e>john</e> and want to manage your system, you will
-probably need to switch your role. You can use <c>newrole</c> for this:
-</p>
-
-<pre caption="Switching roles">
-~$ <i>id -Z</i>
-staff_u:staff_r:staff_t
-~$ <i>newrole -r sysadm_r</i>
-Password: <comment>(Enter your password)</comment>
-~$ <i>id -Z</i>
-staff_u:sysadm_r:sysadm_t
-</pre>
-
-<p>
-If you however use a <c>targeted</c> policy, then the user you work with will be
-of type <e>unconfined_t</e> and will already have the necessary privileges to
-perform system administrative tasks.
-</p>
-
-<p>
-With that done, enjoy - your first steps into the SELinux world are now made.
-</p>
-
-</body>
-</subsection>
-</section>
-</sections>
diff --git a/xml/selinux/hb-using-policies.xml b/xml/selinux/hb-using-policies.xml
deleted file mode 100644
index a67f20b..0000000
--- a/xml/selinux/hb-using-policies.xml
+++ /dev/null
@@ -1,520 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-commands.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>4</version>
-<date>2012-04-29</date>
-
-<section>
-<title>SELinux Policy Language</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-By default, Gentoo provides a generic, yet tightly controlled policy which is
-deemed a good start policy for the majority of users. However, the purpose
-behind a Mandatory Access Control system is to put the security administrator in
-control. As such, a handbook on SELinux without information on how to write
-policies wouldn't be complete.
-</p>
-
-<p>
-In this chapter, we'll talk a bit about the language behind SELinux policies and
-give some pointers on how to create your own policies, roles, etc.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Building a SELinux Module</title>
-<body>
-
-<p>
-First, before we go into the art of SELinux policy writing, let's first make a
-small SELinux module with a rule we can test, build the module and see if things
-work. Although these steps are fairly easy, they are important nonetheless.
-Modifying the SELinux policy as offered by Gentoo is best done through
-additional SELinux policy modules. Only when the core policy (the base policy)
-is not to your liking should you see on using a totally different policy.
-</p>
-
-<p>
-Let's start with a skeleton for a policy module we'll call <e>testmod</e>. You
-should use simple names for the modules as the build infrastructure is quite
-sensitive to special constructs. Use only letters a-z and numbers, and never
-start a module name with a number.
-</p>
-
-<pre caption="Policy module skeleton">
-policy_module(testmod, 1.0.0)
-</pre>
-
-<p>
-Yes, that's it. But as you can see, it is fairly empty. So let's add a rule that
-allows a regular user (in the user_t domain) to read ebuild files (of type
-portage_ebuild_t).
-</p>
-
-<pre caption="Policy module testmod">
-policy_module(testmod, 1.0.0)
-
-require {
- type user_t;
- type portage_ebuild_t;
- class file { read open getattr };
- class dir { read search open getattr };
-}
-
-allow user_t portage_ebuild_t:file { read open getattr };
-allow user_t portage_ebuild_t:dir { read search open getattr };
-</pre>
-
-<p>
-As you can see, something as simple as allowing a user to read a file requires
-quite a few privileges. The directory privileges are needed to allow a user to
-navigate through the Portage tree structure whereas the file privileges are
-needed for a user to be able to access and open the ebuilds. Save this file as
-<path>testmod.te</path>.
-</p>
-
-<p>
-To build the policy and convert it into the binary module that we can load into
-the SELinux policy store, we can use the <path>Makefile</path> available in
-<path>/usr/share/selinux/strict/include</path> (substitute strict with the
-SELinux policy type you are using).
-</p>
-
-<pre caption="Building a binary policy module">
-$ <i>make -f /usr/share/selinux/struct/include/Makefile testmod.pp</i>
-</pre>
-
-<p>
-The filename (<path>testmod.pp</path>) is the destination binary SELinux module
-name. The <path>Makefile</path> will automatically look for the
-<path>testmod.te</path> file you have in the working directory.
-</p>
-
-<p>
-As a result, you should now have a file called <path>testmod.pp</path>. This
-module file can now be loaded in the SELinux policy store as follows:
-</p>
-
-<pre caption="Loading a binary module">
-# <i>semodule -i /path/to/testmod.pp</i>
-</pre>
-
-<p>
-Congratulations! You have now build your first SELinux policy module. If you
-want to disable it, remove it through <c>semodule -r testmod</c>.
-</p>
-
-<p>
-This method of building a policy (using the <path>Makefile</path> and
-<c>semodule</c>) is something that you will need to do every time you want to
-update the SELinux policy on your system. The contents of the policy however
-does change as we will see in the rest of this document.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Getting the SELinux Policy Interfaces</title>
-<body>
-
-<p>
-To streamline policy development, the SELinux policy based on the reference
-policy uses interfaces to access privileges within a module. If you have built
-<path>selinux-base-policy</path> with <c>USE="doc"</c> then this information is
-available at
-<path>/usr/share/doc/selinux-base-policy-<version>/html</path>. It is
-recommended to have this information at hand, since most policy
-development/updates will be done through the interfaces offered by the policy.
-</p>
-
-<p>
-If you are just interested, you can also find these interface definitions <uri
-link="http://oss.tresys.com/docs/refpolicy/api/">online</uri>. Mind you though,
-the online resource is only the reference policy and might differ a bit from the
-policy available within Gentoo.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Using Policy Interfaces</title>
-<body>
-
-<p>
-Using the policy interfaces allows you to update the policy with more readable
-functions. For instance, to allow the user_t domain to call and use Portage
-applications, the module could look like so:
-</p>
-
-<pre caption="Example policy to allow user_t to use portage">
-policy_module(testmod, 1.0.0)
-
-require {
- type user_t;
- role user_r;
-}
-
-portage_run(user_t, user_r)
-</pre>
-
-<p>
-Of course, this makes the user_t domain much more privileged than the previously
-defined rules to read ebuild files: it allows the user to call portage, update
-the system, etc. Of course, the user still requires the proper regular Linux
-permissions (so he needs to be part of the portage group or become root).
-Needless to say, we do not recommend to grant this to a regular user ;-)
-</p>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Full SELinux Policy Modules</title>
-<subsection>
-<title>Checking Out an Isolated Module</title>
-<body>
-
-<p>
-With the above in mind, we can now go one step further and investigate a full
-policy module, with both the type enforcement rules (<path>.te</path> file),
-file contexts (<path>.fc</path>) and interfaces (<path>.if</path>).
-</p>
-
-<p>
-You should know that writing a module requires you to get intimate with the
-application. It isn't a matter of just hoping for the best: as a security
-administrator, you will be responsible for defining what accesses are allowed
-and which not. If you forget one, the application might break under the users'
-hands. But if you add too much, you might grant privileges that can be abused
-later on. And it will be a lot more difficult to track and remove privileges
-later as you will be hesitating if the privilege is needed or not.
-</p>
-
-<p>
-In this section, we will not divulge in how to write one. We have an excellent
-<uri link="/proj/en/hardened/selinux-development.xml">Gentoo Hardened SELinux
-Development</uri> resource that guides you in that. However, we will look into
-such a full module to explain the other aspects of policy development.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Type Enforcement File</title>
-<body>
-
-<p>
-The <path>.te</path> file we wrote earlier is a <e>type enforcement file</e>.
-Its purpose is to define the access rules related to the module that you are
-building, but also - and more importantly - define new types (or even roles).
-</p>
-
-<p>
-The example below is a snippet from a module for the skype application.
-</p>
-
-<pre caption="Snippet from skype.te">
-policy_module(skype, 1.0.0)
-
-type skype_t;
-type skype_exec_t;
-application_domain(skype_t, skype_exec_t)
-
-type skype_home_t;
-userdom_user_home_content(skype_home_t)
-
-manage_dirs_pattern(skype_t, skype_home_t, skype_home_t)
-manage_files_pattern(skype_t, skype_home_t, skype_home_t)
-</pre>
-
-<p>
-In the above example, three new types are declared: <c>skype_t</c> (which will
-be used for the application), <c>skype_exec_t</c> (which is the label given to
-the application binary) and <c>skype_home_t</c> (which will be used for the
-users' <path>~/.Skype</path> location). Also, the <c>skype_t</c> domain is given
-some privileges with respect to the <c>skype_home_t</c> label (manage
-directories and files).
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>File Context File</title>
-<body>
-
-<p>
-In the <path>.fc</path> file (which stands for <e>file context file</e>) the
-module's resources (files, directories, sockets, ...) are defined. Once the
-module is loaded, these rules are added so that file system relabeling will put
-the correct context on the files.
-</p>
-
-<p>
-The example below is a snippet from the skype modules' file context file.
-</p>
-
-<pre caption="Snippet from skype.fc">
-HOME_DIR/\.Skype(/.*)? gen_context(system_u:object_r:skype_home_t,s0)
-/opt/skype/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
-/usr/bin/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
-</pre>
-
-<p>
-The format of the file context file has the following syntax:
-</p>
-
-<ol>
- <li>
- The regular expression that matches the file(s) and directorie(s) affected
- by that line
- </li>
- <li>
- An optional identifier to differentiate the type of files (file, directory,
- socket, symbolic link, ...)
- </li>
- <li>
- A <c>gen_context</c> line that contains the context to assign to the file(s)
- and directorie(s)
- </li>
-</ol>
-
-</body>
-</subsection>
-<subsection>
-<title>Interface File</title>
-<body>
-
-<p>
-In the <path>.if</path> file (for <e>interface file</e>) interfaces are declared
-which can be used by other modules. It is through interfaces that a nicely
-defined policy can be built on top of other, existing policy modules.
-</p>
-
-<p>
-One interface could be to allow users to call and execute an application. For
-instance, the following interface can be found in the skype module.
-</p>
-
-<pre caption="Snippet from skype.if">
-interface(`skype_role',`
- gen_require(`
- type skype_t, skype_exec_t, skype_tmpfs_t, skype_home_t;
- ')
-
- role $1 types skype_t;
-
- domtrans_pattern($2, skype_exec_t, skype_t)
-
- allow $2 skype_t:process { ptrace signal_perms };
-
- manage_dirs_pattern($2, skype_home_t, skype_home_t)
- manage_files_pattern($2, skype_home_t, skype_home_t)
- manage_lnk_files_pattern($2, skype_home_t, skype_home_t)
-
- relabel_dirs_pattern($2, skype_home_t, skype_home_t)
- relabel_files_pattern($2, skype_home_t, skype_home_t)
- relabel_lnk_files_pattern($2, skype_home_t, skype_home_t)
-
- ps_process_pattern($2, skype_t)
-')
-</pre>
-
-<p>
-Through this <c>skype_role</c>, we can then allow users to call skype, as can be
-found in the <path>unprivuser.te</path> file (which defines the user_t domain):
-</p>
-
-<pre caption="Snippet from unprivuser.te to call skype">
-optional_policy(`
- skype_role(user_r, user_t)
-')
-</pre>
-
-<p>
-The following table shows a few common interfaces that could be in use. We
-seriously recommend to look at the available interfaces when enhancing or
-creating your own modules - and be sure to pick the interface that adds just
-what you need, nothing more.
-</p>
-
-<table>
-<tr>
- <th colspan="3">Templates</th>
-</tr>
-<tr>
- <th>Suffix</th>
- <th>Example</th>
- <th>Description</th>
-</tr>
-<tr>
- <ti>_template</ti>
- <ti>virt_domain_template(prefix)</ti>
- <ti>
- Not really an interface, templates create additional domains based on the
- information given to them. This is usually done for fine-grained policy
- templates with a common (sub)set of privileges.
- </ti>
-</tr>
-<tr>
- <th colspan="3">Transformations</th>
-</tr>
-<tr>
- <th>Suffix</th>
- <th>Example</th>
- <th>Description</th>
-</tr>
-<tr>
- <ti></ti>
- <ti>miscfiles_cert_type(resource)</ti>
- <ti>
- Transformation interfaces generally add specific attributes to resources or
- domains. Attributes "transform" the given resource into something more. In
- the given example, the miscfiles_cert_type(resource) assigns the cert_type
- attribute to the resource (and also marks it as a file). Interfaces, like
- miscfiles_read_all_certs work on these attributes.
- </ti>
-</tr>
-<tr>
- <th colspan="3">Access interfaces</th>
-</tr>
-<tr>
- <th>Suffix</th>
- <th>Example</th>
- <th>Description</th>
-</tr>
-<tr>
- <ti>_<access>_<resource></ti>
- <ti>mta_getattr_spool(domain)</ti>
- <ti>
- Grant the specified domain access towards the shown resource. The resource
- usually defines the type too (like kudzu_getattr_exec_files: grant getattr
- on the kudzu_exec_t files) unless it is obvious from the name, or when the
- resource is a more specific term towards the domain. It can also include
- dontaudit (like mta_dontaudit_getattr_spool).
- </ti>
-</tr>
-<tr>
- <ti>_exec</ti>
- <ti>dmesg_exec(domain)</ti>
- <ti>
- Grant one domain the right to execute the given domains' executable file (in
- the example, allow "domain" to execute dmesg_exec_t files), but without
- implying that the domains transition. In other words, dmesg gets executed
- but still confined by the privileges of the source domain.
- </ti>
-</tr>
-<tr>
- <ti>_domtrans</ti>
- <ti>dmesg_domtrans(domain)</ti>
- <ti>
- Grant one domain execute and transition privileges towards the new domain.
- This interface is most commonly used to allow application domains to
- transition to another. In the given example, dmesg is ran with the
- privileges of the dmesg_t domain.
- </ti>
-</tr>
-<tr>
- <ti>_run</ti>
- <ti>netutils_run(domain, role)</ti>
- <ti>
- Grant a given role and domain the rights to execute and transition towards
- the given domain. This is usually granted to (existing) user roles and
- domains and gives them the set of privileges needed to interact safely with
- the new (interactive) domain (such as terminal access).
- </ti>
-</tr>
-<tr>
- <ti>_role</ti>
- <ti>xserver_role(role, domain)</ti>
- <ti>
- Allow the given role and domain the necessary permissions to transition and
- interact with the given domain. This interface is enhanced with the
- privileges to interact with the domain (and its underlying files) more
- thoroughly, and is usually assigned to newly created users or roles within
- the policy (rather than enhance existing user domains and roles).
- </ti>
-</tr>
-<tr>
- <ti>_admin</ti>
- <ti>aide_admin(domain)</ti>
- <ti>
- Grant the given domain the rights to administer the target domains'
- environment. This usually involves privileges to manage and relabel all
- affiliated files, directories, sockets, etc.
- </ti>
-</tr>
-</table>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Using audit2allow</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-When reading online resources on SELinux, you will notice that there are many
-references to a tool called <c>audit2allow</c>. This tools' purpose is to read
-AVC denial messages from the audit log file and transform them into a policy
-module that you can load. The advantage is that it makes it a lot easier to
-write policies. The downside is that the output (unless you use the <c>-R</c>
-option) is not usable for the <path>Makefile</path> we used earlier to build
-modules.
-</p>
-
-<p>
-Another disadvantage is that the tool does not intelligently cope with changes.
-It blindly accepts denials and treats them as if they need to be allowed, rather
-than investigate if no other context should be given to the file, etc.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Using audit2allow</title>
-<body>
-
-<p>
-Using <c>audit2allow</c> is pretty straightforward. You send it the denials you
-want to fix and store the result in a <path>.te</path> file. You then convert it
-into an intermediary format which can then be translated into a <path>.pp</path>
-file for final loading by <c>semodule</c>.
-</p>
-
-<p>
-For instance, to catch all denials and transform them into allowed statements
-from firefox-related denials:
-</p>
-
-<pre caption="Generate a new policy using audit2allow">
-# <i>grep firefox /var/log/avc.log | audit2allow -m firefoxmod > firefoxmod.te</i>
-# <i>checkmodule -m -o firefoxmod.mod firefoxmod.te</i>
-# <i>semodule_package -o firefoxmod.pp -m firefoxmod.mod</i>
-# <i>semodule -i firefoxmod.pp</i>
-</pre>
-
-<p>
-Keep the module name (given through the <c>-m</c> option) simple: only use
-characters (<c>[a-z]</c>) and numbers (<c>[0-9]</c>), and start the module name
-with a character.
-</p>
-
-</body>
-</subsection>
-</section>
-
-</sections>
diff --git a/xml/selinux/hb-using-states.xml b/xml/selinux/hb-using-states.xml
deleted file mode 100644
index ee7f8e1..0000000
--- a/xml/selinux/hb-using-states.xml
+++ /dev/null
@@ -1,367 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-using-commands.xml,v 1.3 2011/06/07 19:46:52 klondike Exp $ -->
-
-<sections>
-<version>2</version>
-<date>2012-04-29</date>
-
-<section>
-<title>SELinux States</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-When SELinux is available, it will generally be in one of three states on your
-system: disabled, permissive or enforcing.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Disabled</title>
-<body>
-
-<p>
-When <c>getenforce</c> returns "Disabled", then SELinux is not running on your
-system. Even though it might be built in your kernel, it is definitely disabled.
-Your system will still run with regular discretionary access controls (the usual
-permission rules for standard Linux environments) but the mandatory access
-controls are not active.
-</p>
-
-<p>
-When SELinux is disabled, it also means that files, directories, etc that are
-modified or created will not get the proper SELinux context assigned to them.
-When you later start your system with SELinux enabled (permissive or enforcing),
-issues will arise since the SELinux subsystem will not know which label the
-files have (it will default the label to one that is not accessible by most
-domains).
-</p>
-
-<p>
-The best way to go forward in such case is to boot in permissive mode and then
-relabel the entire file system:
-</p>
-
-<pre caption="Relabeling the entire file system">
-# <i>rlpkg -a -r</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Permissive</title>
-<body>
-
-<p>
-When SELinux is enabled in permissive mode (<c>getenforce</c> returns
-"Permissive"), then SELinux is enabled and it has a policy loaded. Every access
-a process makes is checked against the policy rules and, if an access is not
-allowed, it will be logged (unless the denial is marked as dontaudit) but it
-will <e>not</e> be prohibited.
-</p>
-
-<p>
-The permissive mode is perfect to get acquainted with SELinux and have the
-system made ready for future "enforcing" mode. While running in permissive mode,
-applications <e>that are not SELinux aware</e> will behave as if SELinux is not
-running. This is perfect to validate if a problem is caused by SELinux or not:
-if in permissive mode the problem still persists, then it is not caused by
-SELinux.
-</p>
-
-<p>
-There is one caveat though: if the application is <e>SELinux-aware</e> (it knows
-that it can run in a SELinux environment and is able to make SELinux-specific
-calls) it might still react differently. Although this is often (but not always)
-a bad programming practice, some applications check if SELinux is enabled and
-base their functional flow on the results, regardless of the state being
-permissive or enforcing.
-</p>
-
-<p>
-To find out if an application is SELinux aware, simply check if it is linked
-against libselinux (with <c>ldd</c> or <c>scanelf</c> - part of
-<path>app-misc/pax-utils</path>):
-</p>
-
-<pre caption="Checking if /bin/ls is SELinux-aware">
-# <i>scanelf -n /bin/ls</i>
- TYPE NEEDED FILE
-ET_DYN libselinux.so.1,librt.so.1,libc.so.6 /bin/ls
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Enforcing</title>
-<body>
-
-<p>
-If <c>getenforce</c> returns "Enforcing", then SELinux is loaded and will act
-based on the policy. When a process tries some activity that is not allowed by
-the policy, it will be logged (unless a dontaudit is set) and the activity will
-not go through. This is the only mode where you can truely say that SELinux is
-active, because it is only now that the policy is acted upon.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Switching States</title>
-<body>
-
-<p>
-Depending on your Linux kernel configuration, you can switch between states
-using one of the following methods. The kernel configuration however can be made
-so that some of these options are disabled (for instance, a fully hardened
-system will not allow disabling SELinux in any way).
-</p>
-
-<p>
-Using the command <c>setenforce</c>:
-</p>
-
-<pre caption="Switching between enforcing and permissive">
-<comment>(Switching to permissive mode)</comment>
-# <i>setenforce 0</i>
-
-<comment>(Switching to enforcing mode)</comment>
-# <i>setenforce 1</i>
-</pre>
-
-<p>
-Using the kernel boot option <c>enforcing</c>:
-</p>
-
-<pre caption="Switching between enforcing and permissive through boot options">
-<comment>(The following GRUB kernel line would boot in permissive mode)</comment>
-kernel /kernel-2.6.39-hardened-r8 root=/dev/md3 rootflags=data=journal <i>enforcing=0</i>
-</pre>
-
-<p>
-Using the <path>/etc/selinux/config</path> <c>SELINUX</c> variable:
-</p>
-
-<pre caption="/etc/selinux/config SELINUX setting">
-# <i>cat /etc/selinux/config</i>
-# This file controls the state of SELinux on the system on boot.
-
-# SELINUX can take one of these three values:
-# enforcing - SELinux security policy is enforced.
-# permissive - SELinux prints warnings instead of enforcing.
-# disabled - No SELinux policy is loaded.
-<i>SELINUX=enforcing</i>
-
-# SELINUXTYPE can take one of these four values:
-# targeted - Only targeted network daemons are protected.
-# strict - Full SELinux protection.
-# mls - Full SELinux protection with Multi-Level Security
-# mcs - Full SELinux protection with Multi-Category Security
-# (mls, but only one sensitivity level)
-SELINUXTYPE=strict
-</pre>
-
-<p>
-When you want to switch from permissive to enforcing, it is recommended to do so
-in the order given above:
-</p>
-
-<ol>
- <li>
- First boot up in permissive mode, log on, verify that your context is
- correct (<c>id -Z</c>) and then switch to enforcing (<c>setenforce 1</c>).
- You can now test if your system is still working properly.
- </li>
- <li>
- Next, boot with <c>enforcing=1</c> as kernel parameter. This way, your
- system will boot in enforcing mode, but if things go haywire, you can just
- reboot, leave out the option and be back in permissive mode
- </li>
- <li>
- Finally, edit <path>/etc/selinux/config</path> to persist this change.
- </li>
-</ol>
-
-</body>
-</subsection>
-<subsection>
-<title>Domain-permissive Mode</title>
-<body>
-
-<p>
-You can also opt to mark a single domain permissive while running the rest of
-the system in an enforcing state. For instance, to mark mplayer_t as a
-permissive domain (which means that SELinux does not enforce anything):
-</p>
-
-<pre caption="Marking mplayer_t as permissive">
-# <i>semanage permissive -a mplayer_t</i>
-</pre>
-
-<p>
-With the <c>-d</c> option, you can remove the permissive mark again.
-</p>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>SELinux Policy Types</title>
-<subsection>
-<title>Introduction</title>
-<body>
-
-<p>
-Next to the SELinux state, SELinux also offers different policy types. These
-types differentiate themselves in specific SELinux features that are enabled or
-disabled. Within Gentoo, three are supported (and a fourth is available):
-<c>targeted</c>, <c>strict</c>, <c>mcs</c> (and <c>mls</c>).
-</p>
-
-<p>
-The type used on a system is declared in <path>/etc/selinux/config</path>:
-</p>
-
-<pre caption="The SELINUXTYPE information in /etc/selinux/config">
-# <i>cat /etc/selinux/config</i>
-# This file controls the state of SELinux on the system on boot.
-
-# SELINUX can take one of these three values:
-# enforcing - SELinux security policy is enforced.
-# permissive - SELinux prints warnings instead of enforcing.
-# disabled - No SELinux policy is loaded.
-SELINUX=enforcing
-
-# SELINUXTYPE can take one of these four values:
-# targeted - Only targeted network daemons are protected.
-# strict - Full SELinux protection.
-# mls - Full SELinux protection with Multi-Level Security
-# mcs - Full SELinux protection with Multi-Category Security
-# (mls, but only one sensitivity level)
-<i>SELINUXTYPE=strict</i>
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>strict (without unconfined domains)</title>
-<body>
-
-<p>
-The <c>strict</c> policy type is the policy type that was described in the
-earlier chapters, and coincidentally the type that is the easiest to understand.
-With the strict policy type, each and every application runs in a domain that
-has limited privileges. Although there are highly privileged domains, they are
-never truely unlimited in their privileges.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>targeted (using unconfined domains)</title>
-<body>
-
-<p>
-The <c>targeted</c> policy type is similar to the strict one, with one major
-addition: support for unconfined domains. Applications (or users) that run in an
-unconfined domain are almost unlimited in their privileges. The unconfined
-domains are usually used for users and user applications, but also the init
-system and other domains are marked as "unconfined" domains.
-</p>
-
-<p>
-The idea behind the targeted policy is that network-facing services are running
-in (confined) regular domains whereas the rest uses the standard discretionary
-access controls offered by Linux. These other domains are running as
-"unconfined".
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>mcs (using multiple categories)</title>
-<body>
-
-<p>
-The introduction of <c>mls</c> and <c>mcs</c> offers the ability for
-<e>multi-tenancy</e>: multiple instances of the same application should be able
-to run, but each instance should be confined with respect to the others (instead
-of all these processes running in the same domain and, hence, the same
-privileges).
-</p>
-
-<p>
-A simple example is virtualization: a virtual guest which runs in the
-<c>qemu_t</c> domain needs write privileges on the image file that contains the
-guest operating system. However, if you run two guests, you do not want each
-guest to write to the other guests' file. With regular domains, you will need to
-provide this. With <c>mcs</c>, you can give each running instance a specific
-category (number) and only grant it write privileges to the guest file with the
-correct category (number).
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>mls (using multiple security levels)</title>
-<body>
-
-<p>
-The <c>mls</c> policy type is available but not yet supported by Gentoo
-Hardened. With this policy type, it is possible to give sensitivity levels on
-files and resources as well as domains. Sensitivity levels can best be expressed
-in terms of <e>public</e>, <e>private</e>, <e>confidential</e> or <e>strictly
-confidential</e>. With MLS, you can mark a file as one (or a set of)
-sensitivity level(s) and ensure that only domains with the right sensitivity
-level can access it.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Switching Types</title>
-<body>
-
-<p>
-It is not recommended to switch between types often. At best, you choose your
-policy type at install time and stick with it. But it is not impossible (nor
-that hard) to switch between types.
-</p>
-
-<p>
-First, you need to edit <path>/etc/selinux/config</path> so that it both
-switches the policy type as well as put the mode in <e>permissive</e>. This is
-necessary, since at your next reboot, many labels might (or will) be incorrect.
-</p>
-
-<p>
-Next, edit <path>/etc/fstab</path> and make sure that the domains you use there
-are updated accordingly. For instance, the line for <path>/tmp</path>:
-</p>
-
-<pre caption="Changing /etc/fstab">
-<comment># Example when switching from strict to mcs</comment>
-tmpfs /tmp tmpfs defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t<i>:c0</i> 0 0
-</pre>
-
-<p>
-When this is done, reboot your system. Log on as root, and relabel your entire
-file system using <c>rlpkg -a -r</c>. Finally, reboot again and then validate if
-your context (such as when logged on as a user) is correct again. Once you are
-confident that the domains and contexts are correct, switch the SELinux policy
-mode back to "enforcing".
-</p>
-
-</body>
-</subsection>
-</section>
-
-</sections>
diff --git a/xml/selinux/hb-using-troubleshoot.xml b/xml/selinux/hb-using-troubleshoot.xml
deleted file mode 100644
index fc0323d..0000000
--- a/xml/selinux/hb-using-troubleshoot.xml
+++ /dev/null
@@ -1,349 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/hb-appendix-troubleshoot.xml,v 1.2 2011/04/25 20:12:59 zorry Exp $ -->
-
-<sections>
-<version>2</version>
-<date>2012-04-10</date>
-
-<section>
-<title>Unable To Load SELinux Policy</title>
-<subsection>
-<title>Problem Description</title>
-<body>
-
-<p>
-If you notice that SELinux is not functioning at all, a quick run of
-<c>sestatus</c> should give you closure if SELinux is enabled and loaded or not.
-If you get the following output, no SELinux policy is loaded:
-</p>
-
-<pre caption="sestatus output">
-SELinux status: disabled
-</pre>
-
-<p>
-If this is the case, read on in this section to find out how to troubleshoot and
-resolve this.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>No Policy Installed</title>
-<body>
-
-<p>
-One potential reason would be that there is no policy to load to begin with.
-Take a look inside <path>/usr/share/selinux/strict</path> or
-<path>/usr/share/selinux/targeted</path> (depending on your configuration) and
-look for a file called <path>base.pp</path>. If no such file exists, you will
-need to install the base policy. This policy is offered by the
-<path>sec-policy/selinux-base-policy</path> package, but it is better to read up
-on the chapter regarding <uri link="?part=2&chap=1">Gentoo SELinux
-Installation / Conversion</uri> as more important changes might be missing.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Policy Not Loaded</title>
-<body>
-
-<p>
-If the <path>base.pp</path> file exists in
-<path>/usr/share/selinux/strict</path> (or <path>targeted/</path>), take a look
-inside <path>/etc/selinux/strict/policy</path>. This location too should contain
-a <path>base.pp</path> policy module (when a SELinux policy is loaded, it is
-copied from the first location to the second).
-</p>
-
-<p>
-If no <path>base.pp</path> file exists, install and load the policy:
-</p>
-
-<pre caption="Installing the base policy">
-~# <i>semodule -n -B</i>
-</pre>
-
-<p>
-This is a one-time operation - once installed and loaded, it will be reloaded
-upon every reboot.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Init Can Not Load the SELinux Policy</title>
-<body>
-
-<p>
-During system boot, the <c>init</c> process is responsible for loading and
-interacting with the SELinux policy in memory. If <c>init</c> does not support
-SELinux, you will get no SELinux support in your environment.
-</p>
-
-<p>
-To verify if <c>init</c> supports SELinux, we need to check if it uses the
-<path>libselinux.so</path> shared object:
-</p>
-
-<pre caption="Checking if init supports SELinux">
-~# <i>ldd /sbin/init</i>
- linux-vdso.so.1 => (0x00006ace30e84000)
- <comment>( You should see something similar to the following line: )</comment>
- libselinux.so.1 => /lib/libselinux.so.1 (0x00006ace30a46000)
- libc.so.6 => /lib/libc.so.6 (0x00006ace306e9000)
- libdl.so.2 => /lib/libdl.so.2 (0x00006ace304e5000)
- /lib64/ld-linux-x86-64.so.2 (0x00006ace30c68000)
-</pre>
-
-<p>
-If this is not the case, make sure that <c>emerge --info</c> shows that the
-selinux USE flag is in place, and reinstall <path>sys-apps/sysvinit</path>. If
-the selinux USE flag is not in place, check your Gentoo profile and make sure it
-points to a <path>selinux/v2refpolicy/...</path> profile.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Policy Store is Corrupt</title>
-<body>
-
-<p>
-If you encounter problems during boot-up or <c>semodule</c> operations which
-fail with loading problems, but cannot be resolved with the above solution, then
-you might need to reinstall the policies after eliminating the corrupt store.
-</p>
-
-<pre caption="Recovering from store corruption">
-~# <i>semodule -n -B</i>
-libsemanage.semanage_load_module: Error while reading from module file
-/etc/selinux/targeted/modules/tmp/base.pp. (No such file or directory)
-
-~# <i>setenforce 0</i>
-~# <i>mv /etc/selinux/targeted /etc/selinux/targeted.old</i>
-~# <i>FEATURES="-selinux" emerge -1av $(qlist -IC sec-policy)</i>
-~# <i>restorecon -R /etc/selinux</i>
-</pre>
-
-<p>
-This will effectively disable the current, corrupted SELinux policy store and
-then use Portage to reinstall all SELinux policy packages that are installed on
-the system. When done, the file contexts of <path>/etc/selinux</path> are
-restored, after which you should be able to continue.
-</p>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Unable to Log On</title>
-<subsection>
-<title>Problem Description</title>
-<body>
-
-<p>
-If you are unable to log on in a particular situation (remote, local, as root,
-as regular user, ...) there are a few possible problems which you might have
-hit. However, to resolve them you'll need to be able to log on to the system as
-<e>sysadm_r</e> in one way or the other.
-</p>
-
-<p>
-If you can not log in as a <e>sysadm_r</e> user, disable SELinux (boot with
-<c>enforcing=0</c>) so that no SELinux enforcements are made. Changes that you
-make in permissive mode are equally effective as in enforcing mode.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Incorrect Context</title>
-<body>
-
-<p>
-In the majority of cases will you find that a security context is incorrect. Run
-<c>sestatus -v</c> and compare the <e>Process contexts</e> or <e>File
-contexts</e> that you see in the output with the next table.
-</p>
-
-<table>
-<tr>
- <th>Process</th>
- <th>Context</th>
- <th>If wrong context...</th>
-</tr>
-<tr>
- <ti>Init context</ti>
- <ti>system_u:system_r:init_t</ti>
- <ti>
- First, verify that init itself is correclty labeled. Check the output of
- the previously run <c>sestatus -v</c> command for the
- <path>/sbin/init</path> file and make sure that it is set to
- system_u:object_r:init_exec_t. If that is not the case, relabel
- <path>sys-apps/sysvinit</path> using <c>rlpkg sysvinit</c>. Also make the
- same checks as in the <uri link="#doc_chap1">Unable To Load SELinux
- Policy</uri> section. Reboot your system and retry.
- </ti>
-</tr>
-<tr>
- <ti>agetty context</ti>
- <ti>system_u:system_r:getty_t</ti>
- <ti>
- Make sure that the <path>/sbin/agetty</path> binary is labeled
- system_u:object_r:getty_exec_t. If not, relabel the
- <path>sys-apps/util-linux</path> package using <c>rlpkg util-linux</c>. Then
- restart all the agetty processes using <c>pkill agetty</c> (they will
- automatically respawn).
- </ti>
-</tr>
-<tr>
- <th>File</th>
- <th>Context</th>
- <th>If wrong context...</th>
-</tr>
-<tr>
- <ti>/bin/login</ti>
- <ti>system_u:object_r:login_exec_t</ti>
- <ti>
- The login binary is part of <path>sys-apps/shadow</path>. Run <c>rlpkg
- shadow</c> to relabel the files of that package and retry logging in.
- </ti>
-</tr>
-<tr>
- <ti>/sbin/unix_chkpwd</ti>
- <ti>system_u:object_r:chkpwd_exec_t</ti>
- <ti>
- This binary is part of the <path>sys-libs/pam</path> package and is used by
- SSH when it is configured to use PAM for user authentication. Relabel the
- package using <c>rlpkg pam</c> and retry logging in.
- </ti>
-</tr>
-<tr>
- <ti>/etc/passwd</ti>
- <ti>system_u:object_r:etc_t</ti>
- <ti rowspan="2">
- The <path>/etc/passwd</path> and <path>/etc/shadow</path> must be labeled
- correctly, otherwise PAM will not be able to authenticate any user. Relabel
- the files through <c>restorecon /etc/passwd /etc/shadow</c> and retry
- logging in.
- </ti>
-</tr>
-<tr>
- <ti>/etc/shadow</ti>
- <ti>system_u:object_r:shadow_t</ti>
-</tr>
-<tr>
- <ti>/bin/bash</ti>
- <ti>system_u:object_r:shell_exec_t</ti>
- <ti>
- The users' shell (in this case, <c>bash</c>) must be labeled correctly so
- the user can transition into the user domain when logging in. To do so,
- relabel the <path>app-shells/bash</path> package using <c>rlpkg bash</c>.
- Then, try logging in again.
- </ti>
-</tr>
-</table>
-
-</body>
-</subsection>
-</section>
-
-<section>
-<title>Unable to Emerge Anything (OSError: [Errno 22] Invalid argument)</title>
-<subsection>
-<title>Problem Description</title>
-<body>
-
-<p>
-When trying to install software with Portage, you get a huge python stacktrace
-and finally the error message <e>OSError: [Errno 22] Invalid argument</e>:
-</p>
-
-<pre caption="Stacktrace dump when portage fails to install software">
-Traceback (most recent call last):
- File "/usr/bin/emerge", line 43, in <module>
- retval = emerge_main()
- File "/usr/lib64/portage/pym/_emerge/main.py", line 1906, in emerge_main
- myopts, myaction, myfiles, spinner)
- File "/usr/lib64/portage/pym/_emerge/actions.py", line 437, in action_build
- retval = mergetask.merge()
-...
- File "/usr/lib64/portage/pym/portage/package/ebuild/doebuild.py", line 104, in _doebuild_spawn
- return spawn(cmd, settings, **kwargs)
- File "/usr/lib64/portage/pym/portage/package/ebuild/doebuild.py", line 1255, in spawn
- return spawn_func(mystring, env=mysettings.environ(), **keywords)
- File "/usr/lib64/portage/pym/portage/_selinux.py", line 105, in wrapper_func
- setexec(con)
- File "/usr/lib64/portage/pym/portage/_selinux.py", line 79, in setexec
- if selinux.setexeccon(ctx) < 0:
-OSError: [Errno 22] Invalid argument
-</pre>
-
-</body>
-</subsection>
-<subsection>
-<title>Wrong Context</title>
-<body>
-
-<p>
-The above error comes when you launch portage (through <c>emerge</c>) while you
-are not in <c>sysadm_t</c> context. You can verify this with <c>id -Z</c>:
-</p>
-
-<pre caption="Checking current context">
-~# <i>id -Z</i>
-system_u:system_r:local_login_t
-</pre>
-
-<p>
-As long as the context isn't <c>sysadm_t</c>, then Portage will break. This is
-because Portage wants to switch its execution context from <c>portage_t</c> to
-<c>portage_sandbox_t</c> but fails (it isn't in <c>portage_t</c> to begin with
-because the user who launched Portage isn't in <c>sysadm_t</c>).
-</p>
-
-<p>
-Please check <uri link="#doc_chap2">Unable to Log On</uri> above first. Also
-make sure that you can <c>dispatch-conf</c> or <c>etc-update</c> after
-installing SELinux so that <path>/etc/pam.d/system-login</path> is updated with
-the right <path>pam_selinux.so</path> calls.
-</p>
-
-</body>
-</subsection>
-<subsection>
-<title>Forcing Installation</title>
-<body>
-
-<p>
-If you need to force Portage to continue regardless (for instance, you were in
-the middle of a SELinux installation so cannot properly resolve such issues
-now), run the <c>emerge</c> command but with <c>FEATURES="-selinux"</c>. This
-will effectively disable Portage' SELinux integration, but allows you to
-continue installing software.
-</p>
-
-<pre caption="Running emerge without selinux support">
-~# <i>FEATURES="-selinux" emerge -u world</i>
-</pre>
-
-<p>
-Make sure that you relabel the entire file system after using this approach!
-Portage will not label the files installed on the system correctly if you
-disable its SELinux support. To relabel the entire file system, use <c>rlpkg -a
--r</c>.
-</p>
-
-</body>
-</subsection>
-</section>
-
-</sections>
diff --git a/xml/selinux/index.xml b/xml/selinux/index.xml
deleted file mode 100644
index 08fc361..0000000
--- a/xml/selinux/index.xml
+++ /dev/null
@@ -1,156 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<?xml-stylesheet href="/xsl/project.xsl" type="text/xsl"?>
-<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
-<!DOCTYPE project SYSTEM "/dtd/project.dtd">
-<!--$Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/index.xml,v 1.43 2011/04/25 20:12:59 zorry Exp $-->
-<project>
-
-<name>SELinux</name>
-<longname>SELinux</longname>
-
-<description>
-SELinux is a system of mandatory access controls. SELinux can enforce
-the security policy over all processes and objects in the system.
-</description>
-
-<longdescription>
-<p>
-This project manages SELinux support in Gentoo. This includes providing
-kernels with SELinux support, providing patches to userland utilities, writing
-strong Gentoo-specific default profiles, and maintaining a good default set of
-policies.
-</p>
-
-<p>
-<uri link="http://www.nsa.gov/research/selinux/index.shtml">Security-Enhanced
-Linux</uri> (SELinux) is a Mandatory Access Control system using type
-enforcement and role-based access control. It is integrated within Linux as a
-<uri link="http://lsm.immunix.org/">Linux Security Module</uri> (LSM)
-implementation. In addition to the kernel portion, SELinux consists of a library
-(libselinux) and userland utilities for compiling policy (checkpolicy), and loading
-policy (policycoreutils), in addition to other user programs.
-</p>
-
-<p>
-One common misconception is that SELinux is a complete security solution. It is
-not. SELinux only provides access control on system objects. It can work well
-with other Hardened projects, such as PaX, for a more complete solution.
-</p>
-
-</longdescription>
-
-<goals>
-<p>
-Our goal is to make SELinux (with Gentoo Hardened) available to more users.
-As a result, we
-</p>
-
-<ul>
- <li>
- develop, improve and maintain the proper documentation and learning
- material for end users to master SELinux
- </li>
- <li>
- maintain a stable yet progressive set of userland tools that are needed
- to interoperate with SELinux on a Linux system (such as the core utilities,
- libselinux and more)
- </li>
- <li>
- focus on the integration of SELinux and SELinux-awareness within the Gentoo
- distribution, offering the necessary feedback on Portage and other utilities
- </li>
- <li>
- develop, improve and maintain a good and secure default policy, based on the
- reference policy, so that end users have no difficulties working with and
- enhancing SELinux within their environment
- </li>
-</ul>
-</goals>
-
-<dev role="lead" description="Documentation, Userspace tools, Policy development">SwifT</dev>
-<dev role="developer" description="Policy development, Userspace tools">pebenito</dev>
-<dev role="developer" description="Policy development, Proxy (non developer contributors)">blueness</dev>
-<dev role="developer" description="Policy development, Support">prometheanfire</dev>
-
-<resource link="/proj/en/hardened/selinux/selinux-handbook.xml">Gentoo SELinux Handbook (concepts, installation, maintenance)</resource>
-<resource link="/proj/en/hardened/selinux-faq.xml">Gentoo SELinux FAQ</resource>
-<resource link="/proj/en/hardened/selinux-development.xml">Gentoo Hardened SELinux Development Guide</resource>
-<resource link="/proj/en/hardened/selinux-bugreporting.xml">Reporting SELinux (policy) bugs</resource>
-<resource link="/proj/en/hardened/selinux-policy.xml">Gentoo Hardened SELinux Development Policy</resource>
-<resource link="/proj/en/hardened/roadmap.xml">Gentoo Hardened Roadmap (includes SELinux development)</resource>
-<resource link="/proj/en/hardened/support-state.xml">Gentoo Hardened Support Matrices (includes SELinux)</resource>
-
-<extrachapter position="devs">
-<title>Contributors</title>
-<section>
-<body>
-
-<p>
-The following people, although non-developer, are actively contributing to the project:
-</p>
-<table>
-<tr><th>Contributor</th><th>Nickname</th><th>Role</th></tr>
-<tr><ti>Chris Richards</ti><ti>gizmo</ti><ti>Policy development, support</ti></tr>
-</table>
-
-</body>
-</section>
-</extrachapter>
-
-<extrachapter position="bottom">
-<title>I Want to Participate</title>
-<section>
-<body>
-<p>
-To participate in the SELinux project first join the mailing list at
-<c>gentoo-hardened@gentoo.org</c>. Then ask if there are plans to support
-something that you are interested in, propose a new subproject that you are
-interested in or choose one of the planned subprojects to work on. You may talk
-to the developers and users in the IRC channel <c>#gentoo-hardened</c> on
-<c>irc.freenode.net</c> for more information or just to chat about the project
-or any subprojects. If you don't have the ability to actively help by
-contributing work we will always need testers to use and audit the SELinux
-policies. All development, testing, feedback, and productive comments will
-be greatly appreciated.
-</p>
-</body>
-</section>
-
-<section>
-<title>Policy Submissions</title>
-<body>
-
-<p>
-The critical component of a SELinux system is having a strong policy. The
-team does its best to support as many daemons as possible. However, we cannot
-create policies for daemons with which we are unfamiliar. But we are happy
-to receive policy submissions for consideration. There are a few requirements:
-</p>
-
-<ul>
- <li>
- Make comments (in the policy and/or bug), so we can understand changes
- from the Reference Policy example policy.
- </li>
- <li>
- The policy should cover common installations. Please do not submit policies
- for odd or nonstandard daemon configurations.
- </li>
- <li>
- We need to know if the policy is dependent on another policy (for example
- rpcd is dependent on portmap) other than base-policy.
- </li>
-</ul>
-
-<p>
-The policy should be submitted on <uri link="http://bugs.gentoo.org/">bugzilla</uri>.
-Please attach the .te and .fc files separately to the bug, not as a tarball.
-The bug should be Cc'ed to <c>selinux@gentoo.org</c> and will be properly
-reassigned by the team.
-</p>
-
-</body>
-</section>
-</extrachapter>
-
-</project>
diff --git a/xml/selinux/selinux-handbook.xml b/xml/selinux/selinux-handbook.xml
deleted file mode 100644
index 9801448..0000000
--- a/xml/selinux/selinux-handbook.xml
+++ /dev/null
@@ -1,199 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!DOCTYPE book SYSTEM "/dtd/book.dtd">
-
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/selinux/selinux-handbook.xml,v 1.11 2011/04/25 20:12:59 zorry Exp $ -->
-
-<book>
-<title>Gentoo SELinux Handbook</title>
-
-<author title="Author">
- <mail link="pebenito@gentoo.org">Chris PeBenito</mail>
-</author>
-<author title="Author">
- <mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail>
-</author>
-<author title="Author">
- Chris Richards
-</author>
-
-<abstract>
-This is the Gentoo SELinux Handbook.
-</abstract>
-
-<!-- The content of this document is licensed under the CC-BY-SA license -->
-<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
-<license/>
-
-<version>4</version>
-<date>2011-09-18</date>
-
-<part>
-<title>Introduction to Gentoo/Hardened SELinux</title>
-<abstract>
-In this part we cover what SELinux is and how it is positioned within the
-Gentoo/Hardened project.
-</abstract>
-
-<chapter>
-<title>Enhancing Linux Security</title>
-<abstract>
-Security is more than enabling a certain framework or installing a different
-Linux kernel. It is a way of working / administrating your Gentoo Linux system.
-We cover a few (generic) best practices, and then elaborate on what Mandatory
-Access Control is and how SELinux fills in this gap.
-</abstract>
- <include href="hb-intro-enhancingsecurity.xml"/>
-</chapter>
-
-<chapter>
-<title>SELinux Concepts</title>
-<abstract>
-To be able to properly work with SELinux, it is vital that you understand a few
-of its concepts like domains, domain transitions and file contexts. Without
-a basic understanding of these aspects, it will be difficult to understand
-how SELinux policies work and how to troubleshoot if things go wrong.
-</abstract>
- <include href="hb-intro-concepts.xml"/>
-</chapter>
-
-<chapter>
-<title>SELinux Resources</title>
-<abstract>
-To get more acquainted with SELinux, many resources exist on the Internet.
-In this chapter we give a quick overview of the various resources as well
-as places where you can get more help when you are fighting with SELinux.
-</abstract>
- <include href="hb-intro-resources.xml"/>
-</chapter>
-
-<!--
-<chapter>
-<title>The SELinux (Reference) Policy</title>
-<abstract>
-To streamline SELinux policy development, a reference policy is being developed
-that is used by all SELinux-supporting distributions. In this chapter we give
-some intel on what this reference policy is and why it is brought to life, but
-also how this policy functions and how its development is progressing. We also
-cover the basics on SELinux policies in general.
-</abstract>
- <include href="hb-intro-referencepolicy.xml"/>
-</chapter>
-
-<chapter>
-<title>SELinux Virtual Machine Support</title>
-<abstract>
-SELinux support is being actively integrated in libvirt and other
-virtualization frameworks to elevate the security of virtualized
-environments. Within this chapter we give you a first introduction
-on how this is done for libvirt managed environments and what you need to take
-into account if you wish to use SELinux within your virtualized environment.
-</abstract>
- <include href="hb-intro-virtualization.xml"/>
-</chapter>
--->
-</part>
-
-<part>
-<title>Using Gentoo/Hardened SELinux</title>
-<abstract>
-With the theoretic stuff behind us, let us start by installing Gentoo/Hardened
-with a SELinux kernel as well as the SELinux tools.
-</abstract>
-
-<chapter>
-<title>Gentoo SELinux Installation / Conversion</title>
-<abstract>
-To set up SELinux within Gentoo/Hardened, you first need to install Gentoo with
-the correct Hardened profile (or convert to the Hardened profile) and then
-update your system to become a SELinux-managed system. This chapter will guide
-you through this process.
-</abstract>
- <include href="hb-using-install.xml"/>
-</chapter>
-
-<chapter>
-<title>Configuring SELinux For Your Needs</title>
-<abstract>
-With SELinux now "installed" and enabled (although in permissive mode), we now
-configure it to suit your particular needs. After all, SELinux is a Mandatory
-Access Control system where you, as security administrator, define what is
-allowed and what not.
-</abstract>
- <include href="hb-using-configuring.xml"/>
-</chapter>
-
-<chapter>
-<title>SELinux Commands</title>
-<abstract>
-Let's take a step back and get to know a few more commands. We covered most of
-them in the previous section, but we will now dive a bit deeper in its
-syntax, features and potential pitfalls.
-</abstract>
- <include href="hb-using-commands.xml"/>
-</chapter>
-
-<chapter>
-<title>Permissive, Unconfined, Disabled or What Not...</title>
-<abstract>
-Your system can be in many SELinux states. In this chapter, we help you switch
-between the various states / policies.
-</abstract>
- <include href="hb-using-states.xml"/>
-</chapter>
-
-<chapter>
-<title>Modifying the Gentoo Hardened SELinux Policy</title>
-<abstract>
-Gentoo Hardened offers a default policy, but this might not allow what you want
-(or allows too much). In this chapter we tell you how you can tweak Gentoo's
-policy, or even run your own.
-</abstract>
- <include href="hb-using-policies.xml"/>
-</chapter>
-
-<chapter>
-<title>Troubleshooting SELinux</title>
-<abstract>
-Everything made by a human can and will fail. In this chapter we will try to
-keep track of all potential issues you might come across and how to resolve
-them.
-</abstract>
- <include href="hb-using-troubleshoot.xml"/>
-</chapter>
-</part>
-
-<!--
-<part>
-<title>Advanced SELinux</title>
-<abstract>
-SELinux can be much more integrated in the system. In this part, we describe how
-to enhance SELinux configurations, tuning and securing your system even more.
-</abstract>
-
-<chapter>
-<title>Working with MLS</title>
-<abstract>
-...
-</abstract>
- <include href="hb-advanced-mls.xml"/>
-</chapter>
-
-<chapter>
-<title>Using s(ecure) Virt(ualization)</title>
-<abstract>
-...
-</abstract>
- <include href="hb-advanced-svirt.xml"/>
-</chapter>
-
-<chapter>
-<title>Using Netlabel</title>
-<abstract>
-...
-</abstract>
- <include href="hb-advanced-netlabel.xml"/>
-</chapter>
-</part>
--->
-
-</book>
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-05-26 15:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-04 20:08 [gentoo-commits] proj/hardened-docs:master commit in: xml/, xml/selinux/ Sven Vermeulen
-- strict thread matches above, loose matches on Subject: below --
2012-05-26 15:54 Sven Vermeulen
2011-05-20 19:49 Sven Vermeulen
2011-05-04 22:03 Francisco Blas Izquierdo Riera
2011-02-19 3:45 Francisco Blas Izquierdo Riera
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox