From: "Sven Vermeulen" <sven.vermeulen@siphos.be>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/hardened-docs:master commit in: pdf/, html/selinux/
Date: Sat, 15 Oct 2011 18:26:44 +0000 (UTC) [thread overview]
Message-ID: <a819bfbb710041fd72c982eb8b04085170f60b3f.SwifT@gentoo> (raw)
commit: a819bfbb710041fd72c982eb8b04085170f60b3f
Author: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Sat Oct 15 18:26:28 2011 +0000
Commit: Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
CommitDate: Sat Oct 15 18:26:28 2011 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=a819bfbb
Updating previews
---
html/selinux/hb-using-policies.html | 351 +++++++++++++++++++++++++++++++++++
html/selinux/hb-using-states.html | 48 +++++
pdf/selinux-handbook.pdf | Bin 283466 -> 302235 bytes
3 files changed, 399 insertions(+), 0 deletions(-)
diff --git a/html/selinux/hb-using-policies.html b/html/selinux/hb-using-policies.html
new file mode 100644
index 0000000..a40c051
--- /dev/null
+++ b/html/selinux/hb-using-policies.html
@@ -0,0 +1,351 @@
+<!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 Handbook Page
+--
+ </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">
+<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
+ </span>SELinux Policy Language</p>
+<p class="secthead"><a name="doc_chap1_sect1">Introduction</a></p>
+<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>
+<p class="secthead"><a name="doc_chap1_sect1">Building a SELinux Module</a></p>
+<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 <span class="emphasis">testmod</span>.
+</p>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Policy module skeleton</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+policy_module(testmod, 1.0.0)
+</pre></td></tr>
+</table>
+<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>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Policy module testmod</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+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></td></tr>
+</table>
+<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
+<span class="path" dir="ltr">testmod.te</span>.
+</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 <span class="path" dir="ltr">Makefile</span> available in
+<span class="path" dir="ltr">/usr/share/selinux/strict/include</span> (substitute strict with the
+SELinux policy type you are using).
+</p>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Building a binary policy module</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+$ <span class="code-input">make -f /usr/share/selinux/struct/include/Makefile testmod.pp</span>
+</pre></td></tr>
+</table>
+<p>
+The filename (<span class="path" dir="ltr">testmod.pp</span>) is the destination binary SELinux module
+name. The <span class="path" dir="ltr">Makefile</span> will automatically look for the
+<span class="path" dir="ltr">testmod.te</span> file you have in the working directory.
+</p>
+<p>
+As a result, you should now have a file called <span class="path" dir="ltr">testmod.pp</span>. This
+module file can now be loaded in the SELinux policy store as follows:
+</p>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Loading a binary module</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+# <span class="code-input">semodule -i /path/to/testmod.pp</span>
+</pre></td></tr>
+</table>
+<p>
+Congratulations! You have now build your first SELinux policy module. If you
+want to disable it, remove it through <span class="code" dir="ltr">semodule -r testmod</span>.
+</p>
+<p>
+This method of building a policy (using the <span class="path" dir="ltr">Makefile</span> and
+<span class="code" dir="ltr">semodule</span>) 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>
+<p class="secthead"><a name="doc_chap1_sect1">Getting the SELinux Policy Interfaces</a></p>
+<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
+<span class="path" dir="ltr">selinux-base-policy</span> with <span class="code" dir="ltr">USE="doc"</span> then this information is
+available at
+<span class="path" dir="ltr">/usr/share/doc/selinux-base-policy-<version>/html</span>. 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 <a href="http://oss.tresys.com/docs/refpolicy/api/">online</a>. Mind you though,
+the online resource is only the reference policy and might differ a bit from the
+policy available within Gentoo.
+</p>
+<p class="secthead"><a name="doc_chap1_sect1">Using Policy Interfaces</a></p>
+<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>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Example policy to allow user_t to use portage</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+policy_module(testmod, 1.0.0)
+
+require {
+ type user_t;
+ role user_r;
+}
+
+portage_run(user_t, user_r)
+</pre></td></tr>
+</table>
+<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>
+<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
+ </span>Full SELinux Policy Modules</p>
+<p class="secthead"><a name="doc_chap1_sect1">Checking Out an Isolated Module</a></p>
+<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 (<span class="path" dir="ltr">.te</span> file),
+file contexts (<span class="path" dir="ltr">.fc</span>) and interfaces (<span class="path" dir="ltr">.if</span>).
+</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
+<a href="selinux-development.html">Gentoo Hardened SELinux
+Development</a> resource that guides you in that. However, we will look into
+such a full module to explain the other aspects of policy development.
+</p>
+<p class="secthead"><a name="doc_chap1_sect1">Type Enforcement File</a></p>
+<p>
+The <span class="path" dir="ltr">.te</span> file we wrote earlier is a <span class="emphasis">type enforcement file</span>.
+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>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Snippet from skype.te</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+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></td></tr>
+</table>
+<p>
+In the above example, three new types are declared: <span class="code" dir="ltr">skype_t</span> (which will
+be used for the application), <span class="code" dir="ltr">skype_exec_t</span> (which is the label given to
+the application binary) and <span class="code" dir="ltr">skype_home_t</span> (which will be used for the
+users' <span class="path" dir="ltr">~/.Skype</span> location). Also, the <span class="code" dir="ltr">skype_t</span> domain is given
+some privileges with respect to the <span class="code" dir="ltr">skype_home_t</span> label (manage
+directories and files).
+</p>
+<p class="secthead"><a name="doc_chap1_sect1">File Context File</a></p>
+<p>
+In the <span class="path" dir="ltr">.fc</span> file (which stands for <span class="emphasis">file context file</span>) 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>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Snippet from skype.fc</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+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></td></tr>
+</table>
+<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 <span class="code" dir="ltr">gen_context</span> line that contains the context to assign to the file(s)
+ and directorie(s)
+ </li>
+</ol>
+<p class="secthead"><a name="doc_chap1_sect1">Interface File</a></p>
+<p>
+In the <span class="path" dir="ltr">.if</span> file (for <span class="emphasis">interface file</span>) 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>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Snippet from skype.if</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+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></td></tr>
+</table>
+<p>
+Through this <span class="code" dir="ltr">skype_role</span>, we can then allow users to call skype, as can be
+found in the <span class="path" dir="ltr">unprivuser.te</span> file (which defines the user_t domain):
+</p>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Snippet from unprivuser.te to call skype</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+optional_policy(`
+ skype_role(user_r, user_t)
+')
+</pre></td></tr>
+</table>
+<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
+ </span>Using audit2allow</p>
+<p class="secthead"><a name="doc_chap1_sect1">Introduction</a></p>
+<p>
+When reading online resources on SELinux, you will notice that there are many
+references to a tool called <span class="code" dir="ltr">audit2allow</span>. 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 <span class="code" dir="ltr">-R</span>
+option) is not usable for the <span class="path" dir="ltr">Makefile</span> 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>
+<p class="secthead"><a name="doc_chap1_sect1">Using audit2allow</a></p>
+<p>
+Using <span class="code" dir="ltr">audit2allow</span> is pretty straightforward. You send it the denials you
+want to fix and store the result in a <span class="path" dir="ltr">.te</span> file. You then convert it
+into an intermediary format which can then be translated into a <span class="path" dir="ltr">.pp</span>
+file for final loading by <span class="code" dir="ltr">semodule</span>.
+</p>
+<p>
+For instance, to catch all denials and transform them into allowed statements
+from firefox-related denials:
+</p>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Generate a new policy using audit2allow</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+# <span class="code-input">grep firefox /var/log/avc.log | audit2allow -m firefoxmod > firefoxmod.te</span>
+# <span class="code-input">checkmodule -m -o firefoxmod.mod firefoxmod.te</span>
+# <span class="code-input">semodule_package -o firefoxmod.pp -m firefoxmod.mod</span>
+# <span class="code-input">semodule -i firefoxmod.pp</span>
+</pre></td></tr>
+</table>
+</td>
+<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px">
+<tr><td class="topsep" align="center"><p class="alttext">Updated October 15, 2011</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-states.html b/html/selinux/hb-using-states.html
index cf8785d..41e19bd 100644
--- a/html/selinux/hb-using-states.html
+++ b/html/selinux/hb-using-states.html
@@ -149,6 +149,25 @@ Using the <span class="path" dir="ltr">/etc/selinux/config</span> <span class="c
SELINUXTYPE=strict
</pre></td></tr>
</table>
+<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 (<span class="code" dir="ltr">id -Z</span>) and then switch to enforcing (<span class="code" dir="ltr">setenforce 1</span>).
+ You can now test if your system is still working properly.
+ </li>
+ <li>
+ Next, boot with <span class="code" dir="ltr">enforcing=1</span> 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 <span class="path" dir="ltr">/etc/selinux/config</span> to persist this change.
+ </li>
+</ol>
<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
</span>SELinux Policy Types</p>
<p class="secthead"><a name="doc_chap1_sect1">Introduction</a></p>
@@ -231,6 +250,35 @@ confidential</span>. 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>
+<p class="secthead"><a name="doc_chap1_sect1">Switching Types</a></p>
+<p>
+It is not recommended to switch between types often. At best, you choose your
+policy type at install type and stick with it. But it is not impossible (nor
+that hard) to switch between types.
+</p>
+<p>
+First, you need to edit <span class="path" dir="ltr">/etc/selinux/config</span> so that it both
+switches the policy type as well as put the mode in <span class="emphasis">permissive</span>. This is
+necessary, since at your next reboot, many labels might (or will) be incorrect.
+</p>
+<p>
+Next, edit <span class="path" dir="ltr">/etc/fstab</span> and make sure that the domains you use there
+are updated accordingly. For instance, the line for <span class="path" dir="ltr">/tmp</span>:
+</p>
+<a name="doc_chap1_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
+<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing1.1: Changing /etc/fstab</p></td></tr>
+<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
+<span class="code-comment"># Example when switching from strict to mcs</span>
+tmpfs /tmp tmpfs defaults,noexec,nosuid,rootcontext=system_u:object_r:tmp_t<span class="code-input">:c0</span> 0 0
+</pre></td></tr>
+</table>
+<p>
+When this is done, reboot your system. Log on as root, and relabel your entire
+file system using <span class="code" dir="ltr">rlpkg -a -r</span>. 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>
</td>
<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px">
<tr><td class="topsep" align="center"><p class="alttext">Updated October 15, 2011</p></td></tr>
diff --git a/pdf/selinux-handbook.pdf b/pdf/selinux-handbook.pdf
index b267943..cdb8c9b 100644
Binary files a/pdf/selinux-handbook.pdf and b/pdf/selinux-handbook.pdf differ
next reply other threads:[~2011-10-15 18:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-15 18:26 Sven Vermeulen [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-10-15 15:20 [gentoo-commits] proj/hardened-docs:master commit in: pdf/, html/selinux/ Sven Vermeulen
2011-07-21 19:13 Sven Vermeulen
2011-06-09 17:24 Sven Vermeulen
2011-05-03 21:06 Sven Vermeulen
2011-05-03 20:12 Sven Vermeulen
2011-04-16 9:07 Sven Vermeulen
2011-04-15 19:13 Sven Vermeulen
2011-03-09 16:54 Sven Vermeulen
2011-03-02 20:57 Sven Vermeulen
2011-02-24 21:21 Sven Vermeulen
2011-02-13 18:23 Sven Vermeulen
2011-02-12 23:45 Sven Vermeulen
2011-02-12 17:35 Sven Vermeulen
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=a819bfbb710041fd72c982eb8b04085170f60b3f.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