public inbox for gentoo-commits@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Sven Vermeulen" <sven.vermeulen@siphos.be>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/hardened-docs:master commit in: xml/
Date: Tue, 22 Nov 2011 20:08:13 +0000 (UTC)	[thread overview]
Message-ID: <cf4aaf2bf53d3dd358a54e3253796d23a0f33395.SwifT@gentoo> (raw)

commit:     cf4aaf2bf53d3dd358a54e3253796d23a0f33395
Author:     Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
AuthorDate: Tue Nov 22 20:05:18 2011 +0000
Commit:     Sven Vermeulen <sven.vermeulen <AT> siphos <DOT> be>
CommitDate: Tue Nov 22 20:05:18 2011 +0000
URL:        http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=cf4aaf2b

Adding SELinux bugreporting guide

---
 xml/selinux-bugreporting.xml |  171 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 171 insertions(+), 0 deletions(-)

diff --git a/xml/selinux-bugreporting.xml b/xml/selinux-bugreporting.xml
new file mode 100644
index 0000000..bfc13ad
--- /dev/null
+++ b/xml/selinux-bugreporting.xml
@@ -0,0 +1,171 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
+<!-- $Header$ -->
+
+<guide link="/proj/en/hardened/selinux-policy.xml" lang="en">
+<title>Gentoo Hardened SELinux Development Policy</title>
+
+<author title="Author">
+  <mail link="swift"/>
+</author>
+
+<abstract>
+This guide helps users to create a properly filled out bug report for SELinux
+policy updates.
+</abstract>
+
+<!-- The content of this document is licensed under the CC-BY-SA license -->
+<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
+<license/>
+
+<version>1</version>
+<date>2011-11-22</date>
+
+<chapter>
+<title>So you got a bug?</title>
+<section>
+<title>Introduction</title>
+<body>
+
+<p>
+When working with a SELinux-enabled system, you will notice that some policies
+are far from perfect. That is to be expected, since there are a lot more
+policies and SELinux policy modules than we can thoroughly test. That is why bug
+reports are very important for us as they give us much-needed feedback on the
+state of the policies. Also, since we follow the reference policy closely,
+patches are also sent upstream so that other distributions can benefit from the
+updates.
+</p>
+
+<p>
+However, debugging and fixing SELinux policies also means that we need to
+identify a proper policy failure, find the root cause of this failure and have
+an optimal solution. Since we are talking about <e>security</e> policies, much
+attention goes into details, but also in the <e>many eyes</e> paradigm to
+validate if a policy fix is correct or not.
+</p>
+
+<p>
+That is one of the reasons why we created this bugreport as it helps you, as the
+feedback-providing user, to both properly figure out why a failure occurs and
+how to fix it, but also why we are quite strict in the acceptance of patches.
+</p>
+
+</body>
+</section>
+<section>
+<title>Short version</title>
+<body>
+
+<p>
+When reporting SELinux policy fixes based on AVC denials,
+</p>
+
+<ul>
+  <li>
+    structure the denials and try to create one bug report per logically
+    coherent set of denials. Don't push all your AVC denials onto us.
+  </li>
+  <li>
+    make sure you can reproduce the issue and that you have the ability to
+    reproduce while we work on the fix. We cannot test all policies ourselves.
+  </li>
+  <li>
+    report the application failure output as well, not only the AVC denial. We
+    need to know what the application is trying to do (and failing to do) to fix
+    the problem.
+  </li>
+</ul>
+
+</body>
+</section>
+</chapter>
+
+<chapter>
+<title>Bugs related to AVC denials (and non-functional applications)</title>
+<section>
+<title>About</title>
+<body>
+
+<p>
+In this section, we'll go into the details of creating a helpful bug report for
+SELinux policies in case you have an AVC denial (which means SELinux is
+prohibiting a certain privilege request) that results in the failure of the
+application.
+</p>
+
+</body>
+</section>
+<section>
+<title>Structure the denials</title>
+<body>
+
+<p>
+When you get one or more AVC denials, try to structure them into logically
+coherent sets. We cannot easily deal with several dozen denials. Most of the
+time, you either get multiple denials of the same cause, or the denials are not
+truely related.
+</p>
+
+<p>
+When we need to fix the SELinux policy, nine out of ten times we focus on one or
+a few related denials and come up with a proper fix. When there is an abundance
+of AVC denials, we need to skim through them (which we usually then do one at a
+time) which puts a lot of stress on you (the reporter) as we will ask you
+hundred-and-one questions and requests for testing.
+</p>
+
+</body>
+</section>
+<section>
+<title>Prepare for testing</title>
+<body>
+
+<p>
+When you report a SELinux policy related bug, make sure you are ready to test
+the results that we want to put in. We cannot test out all applications
+ourselves. Sometimes, a failure is even only reproducable on a specific setup.
+</p>
+
+</body>
+</section>
+<section>
+<title>Report the application failure</title>
+<body>
+
+<p>
+More than once, we get bug reports on SELinux policy denials where the user is
+still running in permissive mode. He is reporting the denials because he is
+afraid that he will not be able to run it in enforcing mode without the denials
+being fixed.
+</p>
+
+<p>
+However, denials can be <e>cosmetic</e>, in which case we should actually hide
+the denials rather than allow their requests. Also, when you run in permissive
+mode, it is very much possible that the denials would never be reached when
+running in enforcing mode because of earlier denials (which, coincidentally,
+might be wrongly hidden from your logs).
+</p>
+
+<p>
+For this reason, we urge you to give us not only the AVC denial information, but
+also the application failure log output when running in enforcing mode.
+</p>
+
+<p>
+The <uri link="selinux/selinux-handbook.xml">Gentoo Hardened SELinux
+Handbook</uri> will guide you through the process of migrating from a permissive
+system into an enforcing mode. If you believe that booting in enforcing is not
+possible yet, just boot in permissive, log on as root, run <c>setenforce 1</c>
+and only then log on as user(s) to reproduce your situation. There is also a
+<uri link="selinux/selinux-handbook.xml?part=2&amp;chap=2">Troubleshooting
+SELinux</uri> section that helps you identify common bottlenecks or issues while
+trying to get SELinux running on your system.
+</p>
+
+</body>
+</section>
+</chapter>
+
+</guide>



             reply	other threads:[~2011-11-22 20:08 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-22 20:08 Sven Vermeulen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-01-12 13:18 [gentoo-commits] proj/hardened-docs:master commit in: xml/ Magnus Granberg
2012-08-20 17:17 Sven Vermeulen
2012-07-10 19:45 Michael Palimaka
2012-05-26 19:25 Sven Vermeulen
2012-05-26 18:07 Sven Vermeulen
2012-05-21 19:08 Sven Vermeulen
2012-05-04 20:19 Sven Vermeulen
2012-04-28 19:23 Francisco Blas Izquierdo Riera
2012-04-05 20:45 Sven Vermeulen
2012-04-05 18:51 Sven Vermeulen
2012-04-02 15:50 Francisco Blas Izquierdo Riera
2012-03-28 19:00 Sven Vermeulen
2011-12-27 12:51 Sven Vermeulen
2011-12-26 12:17 Sven Vermeulen
2011-12-10 17:32 Sven Vermeulen
2011-12-10 15:44 Sven Vermeulen
2011-12-10 14:47 Sven Vermeulen
2011-11-22 20:08 Sven Vermeulen
2011-11-22 20:08 Sven Vermeulen
2011-11-17 21:36 Sven Vermeulen
2011-11-17 20:51 Sven Vermeulen
2011-11-17 20:32 Sven Vermeulen
2011-11-17 20:30 Sven Vermeulen
2011-11-12 21:27 Sven Vermeulen
2011-10-28 17:36 José María Alonso
2011-10-25 18:35 Sven Vermeulen
2011-10-13 14:49 Sven Vermeulen
2011-10-08 16:54 Sven Vermeulen
2011-09-04 19:54 Sven Vermeulen
2011-09-04 19:54 Sven Vermeulen
2011-09-04 19:13 Sven Vermeulen
2011-09-03 12:10 Sven Vermeulen
2011-08-24 21:09 Sven Vermeulen
2011-08-22 19:20 Sven Vermeulen
2011-08-12 21:00 Sven Vermeulen
2011-08-10 18:38 Sven Vermeulen
2011-07-21 19:47 Sven Vermeulen
2011-07-16 20:33 Sven Vermeulen
2011-07-15 16:08 Sven Vermeulen
2011-07-13 22:04 Sven Vermeulen
2011-07-13 21:39 Sven Vermeulen
2011-07-11 15:03 José María Alonso
2011-07-10 20:09 Sven Vermeulen
2011-06-13 14:14 Sven Vermeulen
2011-06-13 14:14 Sven Vermeulen
2011-06-11 13:16 Francisco Blas Izquierdo Riera
2011-06-10 18:07 Francisco Blas Izquierdo Riera
2011-06-10 18:03 Francisco Blas Izquierdo Riera
2011-06-10 14:56 José María Alonso
2011-06-09 17:36 Francisco Blas Izquierdo Riera
2011-06-01 21:26 Sven Vermeulen
2011-06-01 19:57 Sven Vermeulen
2011-05-24 20:37 Sven Vermeulen
2011-05-22 21:35 Sven Vermeulen
2011-05-22 21:35 Sven Vermeulen
2011-05-14 12:51 Sven Vermeulen
2011-05-14 12:51 Sven Vermeulen
2011-05-10  2:34 Francisco Blas Izquierdo Riera
2011-05-09 21:45 Francisco Blas Izquierdo Riera
2011-05-04 22:03 Francisco Blas Izquierdo Riera
2011-05-04 22:03 Francisco Blas Izquierdo Riera
2011-05-03 21:06 Sven Vermeulen
2011-05-03 20:23 Sven Vermeulen
2011-05-01 20:21 Sven Vermeulen
2011-04-30 19:43 Sven Vermeulen
2011-04-30  8:59 Sven Vermeulen
2011-04-23 11:32 Sven Vermeulen
2011-04-23  8:18 Sven Vermeulen
2011-04-22 22:35 Sven Vermeulen
2011-04-22 19:17 Sven Vermeulen
2011-04-22 11:14 Sven Vermeulen
2011-04-22 10:49 Sven Vermeulen
2011-04-05 18:46 Matthew Thode
2011-04-05 18:38 Matthew Thode
2011-03-27  1:09 Francisco Blas Izquierdo Riera
2011-03-27  1:00 Francisco Blas Izquierdo Riera
2011-03-27  0:55 Francisco Blas Izquierdo Riera
2011-03-26 23:49 Francisco Blas Izquierdo Riera
2011-03-09 18:14 Sven Vermeulen
2011-02-26  9:33 Sven Vermeulen
2011-02-24 21:25 Sven Vermeulen
2011-02-24 21:24 Sven Vermeulen
2011-02-21 21:54 Sven Vermeulen
2011-02-19  3:29 Francisco Blas Izquierdo Riera
2011-02-19  3:23 Francisco Blas Izquierdo Riera
2011-02-19  0:14 Francisco Blas Izquierdo Riera
2011-02-18 23:17 Francisco Blas Izquierdo Riera
2011-02-18 16:11 Francisco Blas Izquierdo Riera
2011-02-18  7:07 Francisco Blas Izquierdo Riera
2011-02-15  4:40 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=cf4aaf2bf53d3dd358a54e3253796d23a0f33395.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