1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header$ -->
<guide lang="en">
<title>Reporting SELinux (policy) bugs</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&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>
|
GitWeb