From: "Sven Vermeulen" <sven.vermeulen@siphos.be>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/hardened-docs:master commit in: html/, html/selinux/
Date: Fri, 22 Apr 2011 22:35:40 +0000 (UTC) [thread overview]
Message-ID: <d8673bd593f010a5317e7335f2d5501ffd56cf11.SwifT@gentoo> (raw)
commit: d8673bd593f010a5317e7335f2d5501ffd56cf11
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Fri Apr 22 22:35:36 2011 +0000
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
CommitDate: Fri Apr 22 22:35:36 2011 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=d8673bd5
Updating previews
---
html/selinux-development.html | 681 +++++++++++++++++++++++++++++++++
html/selinux/hb-using-permissive.html | 2 +-
html/selinux/index.html | 42 +--
3 files changed, 692 insertions(+), 33 deletions(-)
diff --git a/html/selinux-development.html b/html/selinux-development.html
new file mode 100644
index 0000000..72f7a56
--- /dev/null
+++ b/html/selinux-development.html
@@ -0,0 +1,681 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<link title="new" rel="stylesheet" href="http://www.gentoo.org/css/main.css" type="text/css">
+<link REL="shortcut icon" HREF="http://www.gentoo.org/favicon.ico" TYPE="image/x-icon">
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/www-gentoo-org.xml" title="Gentoo Website">
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/forums-gentoo-org.xml" title="Gentoo Forums">
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/bugs-gentoo-org.xml" title="Gentoo Bugzilla">
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/packages-gentoo-org.xml" title="Gentoo Packages">
+<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/archives-gentoo-org.xml" title="Gentoo List Archives">
+<title>Gentoo Linux Documentation
+--
+ Gentoo Hardened SELinux Development</title>
+</head>
+<body style="margin:0px;" bgcolor="#ffffff"><table width="100%" border="0" cellspacing="0" cellpadding="0">
+<tr><td valign="top" height="125" bgcolor="#45347b"><a href="http://www.gentoo.org/"><img border="0" src="http://www.gentoo.org/images/gtop-www.jpg" alt="Gentoo Logo"></a></td></tr>
+<tr><td valign="top" align="right" colspan="1" bgcolor="#ffffff"><table border="0" cellspacing="0" cellpadding="0" width="100%"><tr>
+<td width="99%" class="content" valign="top" align="left">
+<br><h1>Gentoo Hardened SELinux Development</h1>
+<form name="contents" action="http://www.gentoo.org">
+<b>Content</b>:
+ <select name="url" size="1" OnChange="location.href=form.url.options[form.url.selectedIndex].value" style="font-family:sans-serif,Arial,Helvetica"><option value="#doc_chap1">1. Introduction</option>
+<option value="#doc_chap2">2. Setting Up Your Environment</option>
+<option value="#doc_chap3">3. A Domain Does Not Function Properly</option>
+<option value="#doc_chap4">4. No Domain Exists (Yet)</option>
+<option value="#doc_chap5">5. Policy Guidelines</option>
+<option value="#doc_chap6">6. Submitting Patches</option>
+<option value="#doc_chap7">7. Running Your Own Policy</option></select>
+</form>
+<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
+ </span>Introduction</p>
+<p class="secthead"><a name="doc_chap1_sect1">About this document...</a></p>
+<p>
+Dealing with Mandatory Access Control is never easy. SELinux might be available
+by default with Linux, enabling it can provide serious headaches - let alone
+developing policies for it. Within Gentoo Hardened, we strive to offer a default
+policy that is flexible enough to match the requirements of most of you (our
+users) yet remain manageable by the limited number of developers that we have.
+To ensure that the policy we offer is up to date, we definitely need help from
+end users and other developers, because developing policies requires intimate
+knowledge of the products they are written for. With over several thousand
+packages, this is just not feasible for a handful of us. Hence, this Gentoo
+Hardened SELinux Development guide.
+</p>
+<p>
+Within this document, we will try to explain how to set up an environment ready
+to build policies yourself and provide patches to Gentoo Hardened. We also cover
+how to deal with malfunctioning domains and even how to create your own, new
+domains from scratch (if we need to). Further down, we give an overview of the
+guidelines that we try to follow during the policy developments and finally
+talk about how to properly create patches and submit them to our <a href="https://bugs.gentoo.org">bugzilla</a> service.
+</p>
+<p>
+For those who want to run Gentoo Hardened with their own policies, we've also
+added a chapter on just that. We know that our policy does not match everyone's
+requirements, so we definitely want to help you run your own too.
+</p>
+<p class="secthead"><a name="doc_chap1_sect2">Intended audience</a></p>
+<p>
+This document is a must-read for everyone willing to provide patches or develop
+the Gentoo Hardened SELinux policies.
+</p>
+<p>
+Other SELinux advanced users might find this document interesting as well.
+</p>
+<p class="secthead"><a name="doc_chap1_sect3">What you need to know</a></p>
+<p>
+This document does assume prior knowledge on SELinux policies and the way the
+reference policy works. For those that need a quick recap, here are the
+highlights...
+</p>
+<ul>
+ <li>
+ SELinux uses <span class="emphasis">domains</span> and <span class="emphasis">types</span> to differentiate its various
+ security objects. A domain is usually referred to as the security context
+ of a process (or group of processes) whereas a type is usually referred to
+ as the label given to a particular resource (file, directory, network
+ interface, socket, network port, ...).
+ </li>
+ <li>
+ <span class="emphasis">SELinux policies</span> describe what interaction is allowed between a
+ domain and the other domains and types it needs to work with. If no policy
+ allows for a particular activity, then the activity is denied.
+ </li>
+ <li>
+ The structure in which policies are written are called <span class="emphasis">SELinux policy
+ modules</span> which contain three parts: a <span class="emphasis">type enforcement file</span> (with
+ suffix <span class="path" dir="ltr">.te</span>) that contains the intra-module permissions, an
+ <span class="emphasis">interface file</span> (with suffix <span class="path" dir="ltr">.if</span>) that contains the
+ inter-module permissions and a <span class="emphasis">file contexts file</span> (with suffix
+ <span class="path" dir="ltr">.fc</span>) that contains the file context definitions for all file
+ resources that are labeled with the type or types defined in the module
+ </li>
+ <li>
+ Inter-domain privileges must be declared through functions in the
+ <span class="emphasis">interface file</span> which can then be called by other modules. This
+ includes the necessary permissions to allow domain transitions
+ </li>
+</ul>
+<p class="chaphead"><a name="doc_chap2"></a><span class="chapnum">2.
+ </span>Setting Up Your Environment</p>
+<p class="secthead"><a name="doc_chap2_sect1">Patching the reference policy</a></p>
+<p>
+Gentoo Hardened builds its policy upon the <a href="http://oss.tresys.com/projects/refpolicy">reference policy</a> as
+provided by <a href="http://www.tresys.com">Tresys</a> and managed through
+an active <a href="http://oss.tresys.com/projects/refpolicy/wiki/HowToContribute">community</a>.
+I suggest to use two workspaces when dealing with SELinux policies for Gentoo
+Hardened: the <span class="path" dir="ltr">hardened</span> one for the Gentoo patched policy, and a
+<span class="path" dir="ltr">local</span> one in which you work and make your patches in.
+</p>
+<p>
+Of course, using a source control system like git can be helpful too. For now,
+Gentoo Hardened doesn't have a git repository where its policies are based from
+(yet). That might sound a bit dull, but it forces the developers to remain as
+close to upstream as possible (and contribute the changes upstream too so that
+newer releases include them automatically). You can definitely use a source
+control system yourself - the only reason we do not use it in this document is
+that it is easier to document without ;-)
+</p>
+<p>
+Let's create the first workspace:
+</p>
+<a name="doc_chap2_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.1: Creating the SELinux policy workspace</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~$ <span class="code-input">mkdir dev/hardened</span>
+~$ <span class="code-input">cd dev/hardened</span>
+~$ <span class="code-input">ebuild /usr/portage/sec-policy/selinux-base-policy/selinux-base-policy-2.20101213-r12.ebuild compile</span>
+~$ <span class="code-input">cp -r /var/tmp/portage/sec-policy/selinux-base-policy-2.20101213-r12/work/* .</span>
+~$ <span class="code-input">rm -rf /var/tmp/portage/sec-policy/selinux-base-policy-2.20101213-r12</span>
+</pre></td></tr>
+</table>
+<p>
+As result, you should have two or three directories in
+<span class="path" dir="ltr">dev/hardened</span> called <span class="path" dir="ltr">refpolicy</span> and <span class="path" dir="ltr">strict</span>
+and/or <span class="path" dir="ltr">targeted</span>. The only one of interest is the
+<span class="path" dir="ltr">strict</span> and/or <span class="path" dir="ltr">targeted</span> one, depending on the policy
+type you are working with. In the remainder of the document, I'm assuming you
+work with <span class="path" dir="ltr">strict</span>.
+</p>
+<p>
+Now the <span class="path" dir="ltr">dev/hardened</span> workspace is patched with the Gentoo Hardened
+SELinux patches applicable to the base policy. Gentoo Hardened has two "flavors"
+of patches:
+</p>
+<ol>
+ <li>
+ <span class="emphasis">Base policy patches</span> contain the patches for the SELinux modules that
+ take part of the base policy as well as all interface patches for the
+ modules
+ </li>
+ <li>
+ <span class="emphasis">Module-specific patches</span> that contain the permissions affecting the
+ domains and types that are defined in a single module (for instance, all
+ interaction between <span class="path" dir="ltr">portage_t</span> and <span class="path" dir="ltr">portage_exec_t</span>
+ or even <span class="path" dir="ltr">portage_t</span> and <span class="path" dir="ltr">portage_fetch_t</span>)
+ </li>
+</ol>
+<p>
+The base policy patches are important to have available at all times. The
+module-specific ones can be added when you work with that particular module.
+</p>
+<p>
+Every time a new revision comes out, you'll need to clean the
+<span class="path" dir="ltr">dev/hardened</span> workspace and rebuild it.
+</p>
+<p class="secthead"><a name="doc_chap2_sect2">Add specific module files</a></p>
+<p>
+To update your policy workspace, use the same tactic as describes
+earlier, but now for the specific SELinux policy module package (like
+<span class="path" dir="ltr">selinux-postfix</span>).
+</p>
+<a name="doc_chap2_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.2: Updating the dev/hardened workspace</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~$ <span class="code-input">ls dev/hardened/strict/policy/modules/*/postfix.te</span>
+dev/hardened/strict/policy/modules/services/postfix.te
+<span class="code-comment"> ^^^^^^^^</span>
+~$ <span class="code-input">ebuild /usr/portage/sec-policy/selinux-postfix/selinux-postfix-2.20101213-r3.ebuild compile</span>
+
+<span class="code-comment"># Next, we copy the postfix.te and postfix.fc files.
+# Do NOT copy the postfix.if file (as the one available there is a stub)</span>
+~$ <span class="code-input">cp /var/tmp/portage/sec-policy/selinux-postfix-2.20101213-r12/work/strict/postfix.te \
+ dev/hardened/strict/policy/modules/services/</span>
+<span class="code-comment"> ^^^^^^^^</span>
+~$ <span class="code-input">cp /var/tmp/portage/sec-policy/selinux-postfix-2.20101213-r12/work/strict/postfix.fc \
+ dev/hardened/strict/policy/modules/services/</span>
+<span class="code-comment"> ^^^^^^^^</span>
+~$ <span class="code-input">rm -rf /var/tmp/portage/sec-policy/selinux-postfix-2.20101213-r12</span>
+</pre></td></tr>
+</table>
+<p>
+Finally, clean up the workspace (as it contains built policies and other
+material we do not want to see in our patches)
+</p>
+<a name="doc_chap2_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.3: Cleaning up the workspace</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~$ <span class="code-input">cd dev/hardened/strict</span>
+~$ <span class="code-input">make clean</span>
+</pre></td></tr>
+</table>
+<p class="secthead"><a name="doc_chap2_sect3">Setting up a local workspace</a></p>
+<p>
+Setting up a local workspace is easy: just copy the <span class="path" dir="ltr">dev/hardened</span>
+one:
+</p>
+<a name="doc_chap2_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.4: Setting up a local workspace</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~$ <span class="code-input">mkdir dev/local</span>
+~$ <span class="code-input">cp -r dev/hardened/strict dev/local/</span>
+</pre></td></tr>
+</table>
+<p class="secthead"><a name="doc_chap2_sect4">Navigating the policy workspace</a></p>
+<p>
+The main location you will work with is
+<span class="path" dir="ltr">dev/local/strict/policy/modules</span>. This location is subdivided in
+categories:
+</p>
+<dl>
+ <dt>admin</dt>
+ <dd>Administrative SELinux policy modules (portage, logrotate, sudo, ...)</dd>
+ <dt>apps</dt>
+ <dd>Application SELinux policy modules (evolution, mozilla, screen, ...)</dd>
+ <dt>kernel</dt>
+ <dd>Kernel specific SELinux policy domains (corenetwork, kernel, ...)</dd>
+ <dt>roles</dt>
+ <dd>Domains specific to SELinux roles (sysadm, user, staff, ...)</dd>
+ <dt>services</dt>
+ <dd>Daemon SELinux policy modules (postfix, apache, squid, ...)</dd>
+ <dt>system</dt>
+ <dd>Core SELinux policy modules (selinuxutil, mount, iptables, ...)</dd>
+</dl>
+<p>
+The categorization is arbitrary and serves no purpose other than keeping the
+modules a but separated. Each module must have a unique name, regardless of the
+category!
+</p>
+<p>
+Inside the categories, the modules are available using their three files
+</p>
+<a name="doc_chap2_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.5: Listing the available sudo files</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~$ <span class="code-input">cd dev/local/strict/policy/modules/admin</span>
+~$ <span class="code-input">ls sudo.*</span>
+sudo.fc sudo.if sudo.te
+</pre></td></tr>
+</table>
+<p class="secthead"><a name="doc_chap2_sect5">Building a module</a></p>
+<p>
+To build a module, go to the location where the module code is. Then, run
+<span class="code" dir="ltr">make</span> with the development Makefile as provided by the reference policy.
+</p>
+<a name="doc_chap2_pre6"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.6: Building the portage module</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~$ <span class="code-input">cd dev/local/strict/policy/modules/admin</span>
+~$ <span class="code-input">make -f ../../../support/Makefile.devel portage.pp</span>
+</pre></td></tr>
+</table>
+<p>
+You now have a <span class="path" dir="ltr">portage.pp</span> file available which you can load (using
+<span class="code" dir="ltr">semodule -i portage.pp</span>).
+</p>
+<p class="secthead"><a name="doc_chap2_sect6">Building the base policy</a></p>
+<p>
+If you want to build the base policy, run <span class="code" dir="ltr">make base</span>.
+</p>
+<a name="doc_chap2_pre7"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing2.7: Building the base policy</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~$ <span class="code-input">cd dev/local/strict</span>
+~$ <span class="code-input">make base</span>
+</pre></td></tr>
+</table>
+<p>
+The result should be a <span class="path" dir="ltr">base.pp</span> file that you can load using
+<span class="code" dir="ltr">semodule -b base.pp</span>. However, if you intend to do a bit more than just
+test this base policy quickly, it is seriously recommended to create your own
+Gentoo overlay for your own <span class="path" dir="ltr">selinux-base-policy</span> and install that
+one as installing a base policy is not only about the policy module itself, but
+also about the include files that will then be stored in
+<span class="path" dir="ltr">/usr/share/selinux/strict/include</span>.
+</p>
+<p class="chaphead"><a name="doc_chap3"></a><span class="chapnum">3.
+ </span>A Domain Does Not Function Properly</p>
+<p class="secthead"><a name="doc_chap3_sect1">Introduction</a></p>
+<p>
+The most likely problem that you are hitting is that a domain does exist in
+Gentoo Hardened SELinux, but that it isn't functioning as it should. To solve
+this problem, it is adviseable to use the following sequence of investigations:
+</p>
+<ol>
+ <li>
+ Is it really SELinux that is restraining your system?
+ </li>
+ <li>
+ Is the problem related to wrong resource labels / security contexts?
+ </li>
+ <li>
+ Is the problem related to intra-module permissions?
+ </li>
+ <li>
+ Is the problem related to inter-module permissions?
+ </li>
+</ol>
+<p class="secthead"><a name="doc_chap3_sect2">Check if SELinux is to blame</a></p>
+<p>
+Make sure that the problem you are seeing is a SELinux-triggered problem. An
+easy way to find out is to run SELinux in permissive mode and try again:
+</p>
+<a name="doc_chap3_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.1: Switching to permissive mode</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">setenforce 0</span>
+</pre></td></tr>
+</table>
+<p>
+This only works if the problem is <span class="emphasis">not</span> to do with a SELinux-aware
+application (unlike <span class="code" dir="ltr">init</span> or <span class="code" dir="ltr">sudo</span> which are linked to the
+libselinux library). SELinux-aware applications might alter their behavior if
+SELinux is set on the system regardless of it running in permissive mode or not.
+A prime example is <span class="code" dir="ltr">vixie-cron</span> (as can be seen in <a href="https://bugs.gentoo.org/show_bug.cgi?id=257111">bug #257111</a>). But
+for applications that are not SELinux aware, this is the easiest method to find
+out if SELinux is to blame or not.
+</p>
+<p>
+If running your system in permissive mode works around the problem, read on. If
+it doesn't, check the regular permissions (<span class="code" dir="ltr">strace</span>'ing the application
+might be a good idea too).
+</p>
+<p class="secthead"><a name="doc_chap3_sect3">Get the proper AVC denials</a></p>
+<p>
+Assuming that we now know that SELinux is to blame, we need to make sure that we
+get the proper AVC denials. Either locate the proper denials in
+<span class="path" dir="ltr">/var/log/avc.log</span> (or <span class="path" dir="ltr">audit.log</span>) around the time that
+you encountered the issue, or run <span class="code" dir="ltr">tail -f /var/log/avc.log</span> and reproduce
+the problem.
+</p>
+<a name="doc_chap3_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.2: Example denials</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">tail -f /var/log/avc.log</span>
+Apr 22 15:03:33 www1 kernel: [16053.303739] type=1400 audit(1303477413.188:283):
+avc: denied { dac_read_search } for pid=21758 comm="rm" capability=2
+scontext=root:sysadm_r:portage_t tcontext=root:sysadm_r:portage_t
+tclass=capability
+</pre></td></tr>
+</table>
+<p>
+Analyzing the meaning of the AVC denial is covered by <a href="selinux/selinux-handbook.xml?part=2&chap=3#avclog">Looking
+at the AVC Log</a> in the Gentoo Hardened SELinux handbook. The denial should
+give you a pointer where to look for. However, it is possible that no denial is
+occurring, or at least no relevant ones.
+</p>
+<p>
+A first step to get potentially more denials is to switch the
+<span class="code" dir="ltr">gentoo_try_dontaudit</span> boolean off. This boolean is used by the Gentoo
+Hardened SELinux developers to hide denials which they assume are cosmetic. As
+these developers are known to have a human side (as well), they are known to
+make mistakes ;-)
+</p>
+<a name="doc_chap3_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.3: Disabling gentoo's dontaudit statements</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">setsebool gentoo_try_dontaudit off</span>
+</pre></td></tr>
+</table>
+<p>
+Retry getting the proper AVC denials.
+</p>
+<p>
+If it still doesn't work, you can disable all <span class="emphasis">dontaudit</span> statements:
+</p>
+<a name="doc_chap3_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.4: Disabling all dontaudit statements</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">semodule -R -D -B</span>
+</pre></td></tr>
+</table>
+<p>
+Retry getting the proper AVC denials.
+</p>
+<p>
+The moment you get the denials you are looking for, isolate them and then undo
+the changes you made earlier:
+</p>
+<a name="doc_chap3_pre5"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.5: Resetting the auditing defaults</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">setsebool gentoo_try_dontaudit on</span>
+~# <span class="code-input">semodule -R -B</span>
+</pre></td></tr>
+</table>
+<p>
+If you still do not see any denials, then check out the <span class="code" dir="ltr">dmesg</span> output for
+other problems. It is possible that SELinux is not even getting to the point of
+the policy, which you will not notice by looking at the AVC denials alone.
+However, the chance of this to happen is very slim - most of the time, you'll
+find the AVC denials you are looking for.
+</p>
+<p class="secthead"><a name="doc_chap3_sect4">Deducing the correct security contexts</a></p>
+<p>
+The next step is to see if we are dealing with the right security contexts. This
+does require a bit of insight in how both the application (that is failing) and
+the policy relate to each other.
+</p>
+<p>
+Say you are having issues with SELinux (re)labeling and you notice the following
+AVC denial:
+</p>
+<a name="doc_chap3_pre6"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.6: AVC denial for setfiles</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+Apr 16 14:39:57 testsys kernel: [ 115.778484] type=1400
+audit(1302957597.827:224): avc: denied { create } for pid=3584
+comm="setfiles" scontext=root:sysadm_r:<span class="code-comment">sysadm_t</span> tcontext=root:sysadm_r:sysadm_t
+tclass=netlink_audit_socket
+</pre></td></tr>
+</table>
+<p>
+In this case, <span class="code" dir="ltr">setfiles</span> is running in the <span class="path" dir="ltr">sysadm_t</span> domain
+even though it should run in <span class="path" dir="ltr">setfiles_t</span>. So check the security
+context of the <span class="code" dir="ltr">setfiles</span> binary as well as the transition rules:
+</p>
+<a name="doc_chap3_pre7"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.7: Checking setfiles context and rules</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">ls -lZ /sbin/setfiles</span>
+-rwxr-xr-x. 1 root root <span class="code-comment">system_u:object_r:bin_t</span> 26464 Apr 9 22:22 /sbin/setfiles
+~# <span class="code-input">sesearch -s sysadm_t -t setfiles_t -c process -p transition -A -d</span>
+Found 1 semantic av rules:
+ allow sysadm_t setfiles_t : process transition ;
+~# <span class="code-input">sesearch -s sysadm_t -t setfiles_exec_t -c file -p execute -A -d</span>
+...
+~# <span class="code-input">sesearch -s setfiles_t -t setfiles_exec_t -c file -p entrypoint -A -d</span>
+...
+</pre></td></tr>
+</table>
+<p>
+In the above (forced) situation, the problem is with the security context of the
+binary - it should have been <span class="path" dir="ltr">setfiles_exec_t</span> instead of
+<span class="path" dir="ltr">bin_t</span>. Usually, entry points are named similarly (like
+<span class="path" dir="ltr">portage_exec_t</span> or <span class="path" dir="ltr">sudo_exec_t</span>). If you are not certain
+about which domain it should be, use <span class="code" dir="ltr">sesearch</span>
+</p>
+<a name="doc_chap3_pre8"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.8: Using sesearch to find the entrypoint type for a domain</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">sesearch -s setfiles_t -c file -p entrypoint -A -d</span>
+Found 1 semantic av rules:
+ allow setfiles_t setfiles_exec_t : file { ioctl ... execute entrypoint open } ;
+</pre></td></tr>
+</table>
+<p>
+The <span class="code" dir="ltr">sesearch</span> utility is extremely powerful to query the SELinux policy
+(which is currently in memory). I also advise you to use the <span class="code" dir="ltr">-C</span> switch to
+see which rules are trigged by certain SELinux booleans:
+</p>
+<a name="doc_chap3_pre9"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.9: Looking for boolean-triggered settings</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">sesearch -s named_t -t named_zone_t -c file -A -d -C</span>
+Found 2 semantic av rules:
+ allow named_t named_zone_t : file { ioctl read getattr lock open } ;
+DT allow named_t named_zone_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ named_write_master_zones ]
+</pre></td></tr>
+</table>
+<p>
+In the above example, the <span class="path" dir="ltr">named_t</span> domain only has write privileges
+on files labeled <span class="path" dir="ltr">named_zone_t</span> if the
+<span class="path" dir="ltr">named_write_master_zones</span> boolean is set (which it currently isn't,
+otherwise the line would stat with ET instead of DT).
+</p>
+<p>
+To gain a bit of insight in the various, available domains, use <span class="code" dir="ltr">seinfo</span>:
+</p>
+<a name="doc_chap3_pre10"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.10: Getting a list of available domains</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">seinfo -t | grep named</span>
+ named_var_run_t
+ named_checkconf_exec_t
+ named_conf_t
+ named_initrc_exec_t
+ named_log_t
+ named_exec_t
+ named_zone_t
+ named_t
+ named_cache_t
+ named_tmp_t
+</pre></td></tr>
+</table>
+<p>
+To gain a bit of insight in the (current) file context rules, use
+<span class="code" dir="ltr">semanage</span>:
+</p>
+<a name="doc_chap3_pre11"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.11: Getting the list of current file context rules</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+~# <span class="code-input">semanage fcontext -l | grep named</span>
+/etc/bind(/.*)? all files system_u:object_r:named_zone_t
+/etc/bind/named\.conf regular file system_u:object_r:named_conf_t
+/etc/rc\.d/init\.d/named regular file system_u:object_r:named_initrc_exec_t
+/etc/rc\.d/init\.d/unbound regular file system_u:object_r:named_initrc_exec_t
+/etc/rndc.* regular file system_u:object_r:named_conf_t
+/etc/unbound(/.*)? all files system_u:object_r:named_conf_t
+/usr/sbin/lwresd regular file system_u:object_r:named_exec_t
+/usr/sbin/named regular file system_u:object_r:named_exec_t
+/usr/sbin/named-checkconf regular file system_u:object_r:named_checkconf_exec_t
+/usr/sbin/unbound regular file system_u:object_r:named_exec_t
+/var/bind(/.*)? all files system_u:object_r:named_cache_t
+/var/bind/pri(/.*)? all files system_u:object_r:named_zone_t
+/var/log/named.* regular file system_u:object_r:named_log_t
+/var/run/bind(/.*)? all files system_u:object_r:named_var_run_t
+/var/run/named(/.*)? all files system_u:object_r:named_var_run_t
+/var/run/ndc socket system_u:object_r:named_var_run_t
+/var/run/unbound(/.*)? all files system_u:object_r:named_var_run_t
+</pre></td></tr>
+</table>
+<p>
+Most of the time, fixing domain issues is a matter of relabeling files (or
+updating the configuration to match the contexts already defined - both work).
+</p>
+<p class="secthead"><a name="doc_chap3_sect5">Intra-module permissions are missing</a></p>
+<p>
+It is possible that you get a denial between correct security contexts, but
+that the permission is just never granted. In this case, you can choose between
+two things:
+</p>
+<ol>
+ <li>
+ Enhance the module so that the particular permission is granted, or
+ </li>
+ <li>
+ Enhance the module with an additional type where the permission is granted,
+ and assign this type/label to the related resources
+ </li>
+</ol>
+<p>
+In both cases you will need to edit the module files (most likely the
+<span class="path" dir="ltr">.te</span> file), build the module, load it, perhaps even relabel the
+files or the package and retry. It is also a good idea to take a look at
+upstream (latest refpolicy repository or the repositories of Fedora and co) and
+see if they have already solved this problem or not.
+</p>
+<p>
+Granting additional permissions between existing domains is the easiest, but
+might introduce additional problems: if this permission is only needed in a
+particular case yet you grant it for all files and resources related to those
+domains, then you are opening up the policy beyond what is necessary. Often,
+creating an additional domain or type can be beneficial.
+</p>
+<p>
+A noticeable example is Portage' support for CVS/SVN/GIT ebuilds (the so-called
+live ebuilds). These ebuilds get their repository and store it in the
+<span class="path" dir="ltr">distfiles/svn+src</span> location, which was by default labelled
+<span class="path" dir="ltr">portage_ebuild_t</span> with only read-access for the
+<span class="path" dir="ltr">portage_sandbox_t</span> domain. However, with those live ebuilds, the
+<span class="path" dir="ltr">portage_sandbox_t</span> domain also needs write privileges to this
+location. Rather than allowing <span class="path" dir="ltr">portage_sandbox_t</span> write privileges
+to <span class="path" dir="ltr">portage_ebuild_t</span>, a new type was created called
+<span class="path" dir="ltr">portage_svnsrc_t</span> for just this location and the rights are
+transferred towards type.
+</p>
+<p class="secthead"><a name="doc_chap3_sect6">Inter-module permissions are needed</a></p>
+<p>
+If the solution for the problem requires permissions between modules, then you
+need to create the proper interface functions in the target domain and call
+these functions from the source domain.
+</p>
+<p>
+TODO extend this explanation, use a common example, like mysql_stream_connect in
+postfix.
+</p>
+<p>
+TODO explain that changes in the interface require rebuilds and reinstallations
+of the base (package, not only .pp file, due to includes). tell that this is the
+reason why selinux-base-policy has that many revisions.
+</p>
+<p class="chaphead"><a name="doc_chap4"></a><span class="chapnum">4.
+ </span>No Domain Exists (Yet)</p>
+<p class="secthead"><a name="doc_chap4_sect1">Reuse existing domains</a></p>
+<p>
+TODO talk about potentially reusing domains (like apache module providing the
+various httpd_* domains which can be reused by lighttpd). Talk about assigning
+the proper labels to the files to see if that is sufficient.
+</p>
+<p class="secthead"><a name="doc_chap4_sect2">Copy from existing domains</a></p>
+<p>
+TODO talk about finding a similar module (apps or service) and start from a
+(slimmed-down) domain. Not recommended as it might already open too much, but it
+is a good start, if not to just look at with every denial you get later. Keep it
+short, most information is in next section.
+</p>
+<p class="secthead"><a name="doc_chap4_sect3">Starting from scratch</a></p>
+<p>
+TODO talk about defining the proper domains, set proper types (like file_type or
+application_type), refer to refpolicy guidelines
+</p>
+<p class="secthead"><a name="doc_chap4_sect4">Testing new modules</a></p>
+<p>
+TODO talk about users trying to do maximum testing (all the way). Also, if they
+want to support unconfined domains too, how they can do this (and should test).
+</p>
+<p class="chaphead"><a name="doc_chap5"></a><span class="chapnum">5.
+ </span>Policy Guidelines</p>
+<p>
+TODO dealing with cosmetic denials
+</p>
+<p>
+TODO resources - gentoo selinux policy, refpolicy guidelines
+</p>
+<p class="chaphead"><a name="doc_chap6"></a><span class="chapnum">6.
+ </span>Submitting Patches</p>
+<p>
+TODO differentiate between base patch and module patch.
+</p>
+<p>
+TODO perhaps talk about file context patches. Perhaps we will not make a new
+build release for it, but stage it to be included in the next release when a
+non-filecontext patch is added?
+</p>
+<p class="chaphead"><a name="doc_chap7"></a><span class="chapnum">7.
+ </span>Running Your Own Policy</p>
+<p>
+TODO describe how to create your own overlay with modules and patchbundles. Also
+usable for developers to stage their ebuild / patch submissions before actually
+putting in git repo. Ensure that naming is consistent (so that ebuild
+dependencies of packages remain).
+</p>
+<p>
+TODO describe how to exclude sec-policy in regular rsync
+</p>
+<br><p class="copyright">
+ The contents of this document are licensed under the <a href="http://creativecommons.org/licenses/by-sa/2.5">Creative Commons -
+ Attribution / Share Alike</a> license.
+ </p>
+<!--
+ <rdf:RDF xmlns="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
+ <License rdf:about="http://creativecommons.org/licenses/by-sa/2.5/">
+ <permits rdf:resource="http://web.resource.org/cc/Reproduction" />
+ <permits rdf:resource="http://web.resource.org/cc/Distribution" />
+ <requires rdf:resource="http://web.resource.org/cc/Notice" />
+ <requires rdf:resource="http://web.resource.org/cc/Attribution" />
+ <permits rdf:resource="http://web.resource.org/cc/DerivativeWorks" />
+ <requires rdf:resource="http://web.resource.org/cc/ShareAlike" />
+ </License>
+ </rdf:RDF>
+--><br>
+</td>
+<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px">
+<tr><td class="topsep" align="center"><p class="altmenu"><a title="View a printer-friendly version" class="altlink" href="selinux-development.xml?style=printable">Print</a></p></td></tr>
+<tr><td class="topsep" align="center"><p class="alttext">Updated April 22, 2011</p></td></tr>
+<tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b>
+When planning to help Gentoo Hardened in the development of SELinux policies,
+or when trying to debug existing policies, this document should help you get
+acquainted with the necessary resources, trips and tricks to get along.
+</p></td></tr>
+<tr><td align="left" class="topsep"><p class="alttext">
+ <a href="mailto:sven.vermeulen@siphos.be" class="altlink"><b>Sven Vermeulen</b></a>
+<br><i>Author</i><br></p></td></tr>
+<tr lang="en"><td align="center" class="topsep">
+<p class="alttext"><b>Donate</b> to support our development efforts.
+ </p>
+<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
+<input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="paypal@gentoo.org"><input type="hidden" name="item_name" value="Gentoo Linux Support"><input type="hidden" name="item_number" value="1000"><input type="hidden" name="image_url" value="http://www.gentoo.org/images/paypal.png"><input type="hidden" name="no_shipping" value="1"><input type="hidden" name="return" value="http://www.gentoo.org"><input type="hidden" name="cancel_return" value="http://www.gentoo.org"><input type="image" src="http://images.paypal.com/images/x-click-but21.gif" name="submit" alt="Donate to Gentoo">
+</form>
+</td></tr>
+<tr lang="en"><td align="center"><iframe src="http://sidebar.gentoo.org" scrolling="no" width="125" height="850" frameborder="0" style="border:0px padding:0x" marginwidth="0" marginheight="0"><p>Your browser does not support iframes.</p></iframe></td></tr>
+</table></td>
+</tr></table></td></tr>
+<tr><td colspan="2" align="right" class="infohead">
+Copyright 2001-2011 Gentoo Foundation, Inc. Questions, Comments? <a class="highlight" href="http://www.gentoo.org/main/en/contact.xml">Contact us</a>.
+</td></tr>
+</table></body>
+</html>
diff --git a/html/selinux/hb-using-permissive.html b/html/selinux/hb-using-permissive.html
index edb5a19..0285dde 100644
--- a/html/selinux/hb-using-permissive.html
+++ b/html/selinux/hb-using-permissive.html
@@ -103,7 +103,7 @@ access is requested which isn't in the cache yet, it is first loaded in the
cache from which the allow/deny is triggered. Hence the "avc" messages and the
<span class="path" dir="ltr">avc.log</span> log file.
</p>
-<p class="secthead"><a name="doc_chap1_sect1">Looking at the AVC Log</a></p>
+<p class="secthead"><a name="avclog"></a><a name="doc_chap1_sect1">Looking at the AVC Log</a></p>
<p>
During regular system operations, you can keep track of the denials through a
simple <span class="code" dir="ltr">tail</span> session:
diff --git a/html/selinux/index.html b/html/selinux/index.html
index 4798084..e1de71a 100644
--- a/html/selinux/index.html
+++ b/html/selinux/index.html
@@ -26,10 +26,9 @@
<option value="#doc_chap4">4. Developers</option>
<option value="#doc_chap5">5. Contributors</option>
<option value="#doc_chap6">6. Subprojects</option>
-<option value="#doc_chap7">7. Planned subprojects</option>
-<option value="#doc_chap8">8. Resources</option>
-<option value="#doc_chap9">9. How Do I Use This?</option>
-<option value="#doc_chap10">10. I Want to Participate</option></select>
+<option value="#doc_chap7">7. Resources</option>
+<option value="#doc_chap8">8. How Do I Use This?</option>
+<option value="#doc_chap9">9. I Want to Participate</option></select>
</form>
<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
</span>Project Description</p>
@@ -130,7 +129,7 @@ project:
</tr>
<tr>
<td class="tableinfo">Daemon Policy</td>
- <td class="tableinfo"></td>
+ <td class="tableinfo">pebenito</td>
<td class="tableinfo">
SELinux policies for common daemons.
</td>
@@ -151,30 +150,6 @@ project:
</tr>
</table>
<p class="chaphead"><a name="doc_chap7"></a><span class="chapnum">7.
- </span>Planned subprojects</p>
-<p>The SELinux
- project has the following subprojects planned:
- </p>
-<table class="ntable">
- <tr>
- <td class="infohead"><b>Project</b></td>
- <td class="infohead"><b>Description</b></td>
- </tr>
- <tr>
- <td class="tableinfo">non-x86 Support</td>
- <td class="tableinfo">
- Profiles, installation guides, and support for non-x86 architectures.
-</td>
- </tr>
- <tr>
- <td class="tableinfo">Desktop</td>
- <td class="tableinfo">
- SELinux support on destktops. This involves enhancements to XFree's
- security, and accompanying policy.
-</td>
- </tr>
- </table>
-<p class="chaphead"><a name="doc_chap8"></a><span class="chapnum">8.
</span>Resources</p>
<p>Resources offered by the
SELinux
@@ -183,13 +158,16 @@ project:
<li>
<a href="selinux/selinux-handbook.html">Gentoo SELinux Handbook</a>
</li>
+ <li>
+ <a href="selinux-faq.html">Gentoo SELinux FAQ</a>
+ </li>
</ul>
-<p class="chaphead"><a name="doc_chap9"></a><span class="chapnum">9.
+<p class="chaphead"><a name="doc_chap8"></a><span class="chapnum">8.
</span>How Do I Use This?</p>
<p>
SELinux can be installed on a new system by following the above install guide.
</p>
-<p class="chaphead"><a name="doc_chap10"></a><span class="chapnum">10.
+<p class="chaphead"><a name="doc_chap9"></a><span class="chapnum">9.
</span>I Want to Participate</p>
<p>
To participate in the SELinux project first join the mailing list at
@@ -203,7 +181,7 @@ project:
policies. All development, testing, feedback, and productive comments will
be greatly appreciated.
</p>
-<p class="secthead"><a name="doc_chap10_sect2">Policy Submissions</a></p>
+<p class="secthead"><a name="doc_chap9_sect2">Policy Submissions</a></p>
<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
next reply other threads:[~2011-04-22 22:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-22 22:35 Sven Vermeulen [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-04-28 19:23 [gentoo-commits] proj/hardened-docs:master commit in: html/, html/selinux/ Francisco Blas Izquierdo Riera
2011-10-15 13:05 Sven Vermeulen
2011-09-04 19:54 Sven Vermeulen
2011-08-24 21:10 Sven Vermeulen
2011-05-24 20:39 Sven Vermeulen
2011-05-15 9:11 Sven Vermeulen
2011-04-22 19:18 Sven Vermeulen
2011-02-19 3:45 Francisco Blas Izquierdo Riera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d8673bd593f010a5317e7335f2d5501ffd56cf11.SwifT@gentoo \
--to=sven.vermeulen@siphos.be \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox