summaryrefslogtreecommitdiff
blob: 38b156dc36fc5d97248789496549d5c6da82502d (plain)
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
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
<?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 -->

<!-- Le contenu de ce document est sous licence CC-BY-SA. -->
<!-- Voir http://creativecommons.org/licenses/by-sa/1.0/deed.fr -->

<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/fr/hardened/selinux/hb-selinux-logremote.xml,v 1.1 2009/02/23 23:43:33 cam Exp $ -->

<sections>
<version>1.4</version>
<date>2004-11-16</date>

<section>
<title>Sommaire</title>
<subsection>
<body>

<p>
Vous devez être dans <c>sysadm_r</c> pour effectuer ces actions.
</p>

<p>
Lancez <c>sestatus -v</c> et cliquez sur le premier contexte qui ne correspond
pas&nbsp;:
</p>

<table>
<tr>
  <th>Processus</th>
  <th>Contexte</th>
</tr>
<tr>
  <ti>Init context</ti>
  <ti><uri link="#doc_chap2">system_u:system_r:init_t</uri></ti>
</tr>
<tr>
  <ti>/usr/sbin/sshd</ti>
  <ti><uri link="#doc_chap3">system_u:system_r:sshd_t</uri></ti>
  </tr>
<tr>
  <th>File</th>
  <th>Context</th>
</tr>
<tr>
  <ti>/sbin/unix_chkpwd</ti>
  <ti><uri link="#doc_chap4">system_u:object_r:chkpwd_exec_t</uri></ti>
</tr>
<tr>
  <ti>/etc/passwd</ti>
  <ti><uri link="#doc_chap5">system_u:object_r:etc_t</uri></ti>
</tr>
<tr>
  <ti>/etc/shadow</ti>
  <ti><uri link="#doc_chap5">system_u:object_r:shadow_t</uri></ti>
</tr>
<tr>
  <ti>/bin/bash</ti>
  <ti><uri link="#doc_chap6">system_u:object_r:shell_exec_t</uri></ti>
</tr>
</table>

</body>
</subsection>
</section>

<section>
<title>Le contexte d'init est incorrect</title>
<subsection>
<title>Vérifier l'étiquette d'init</title>
<body>

<p>
Plusieurs raisons peuvent être à l'origine d'un mauvais contexte pour init.
Tout d'abord, vérifiez qu'init est correctement étiqueté en vous référant au
résultat de sestatus concernant <path>/sbin/init</path>. Si ce n'est pas
<c>system_u:object_r:init_exec_t</c>, ré-étiquetez sysvinit.
</p>

<pre caption="Réparer le contexte d'init">
# <i>rlpkg sysvinit</i>
</pre>

</body>
</subsection>
<subsection>
<title>Vérifier la disponibilité de la politique</title>
<body>

<p>
Vous devez être dans <c>sysadm_r</c> pour effectuer cette action.
</p>

<p>
Une politique binaire doit être disponible dans
<path>/etc/selinux/{strict,targeted}/policy</path>. Si ce n'est pas le cas,
installez la politique.
</p>

<pre caption="Installer la politique">
# <i>semodule -n -B</i>
</pre>

</body>
</subsection>
<subsection>
<title>Vérifier qu'init peut charger la politique</title>
<body>

<p>
La dernière vérification consiste à s'assurer qu'<c>init</c> puisse charger la
politique. Exécutez <c>ldd</c> sur <path>/sbin/init</path> et, si libselinux ne
fait pas partie des bibliothèques listées, réinstallez sysvinit.
</p>

<pre caption="Vérifier la liaison d'init à libselinux">
# <i>ldd /sbin/init</i>
  linux-gate.so.1 =>  (0xffffe000)
  <comment>libselinux.so.1 => /lib/libselinux.so.1 (0x40025000)</comment>
  libc.so.6 => /lib/libc.so.6 (0x40035000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
</pre>

<p>
Maintenant, redémarrez afin qu'init obtienne le bon contexte et puisse charger
la politique.
</p>

</body>
</subsection>
</section>

<section>
<title>Le contexte de Sshd est incorrect</title>
<subsection>
<body>

<p>
Une autre possibilité est que sshd ne soit pas étiqueté correctement et qu'il
ne tourne donc pas dans le bon domaine. Ré-étiquetez openssh, puis relancez
sshd.
</p>

<pre caption="Réparer le contexte de sshd">
# <i>rlpkg openssh</i>
# <i>/etc/init.d/sshd restart</i>
</pre>

</body>
</subsection>
</section>

<section>
<title>Le contexte de PAM est incorrect</title>
<subsection>
<body>

<p>
Sshd doit pouvoir utiliser PAM pour authentifier les utilisateurs. Le programme
de PAM qui vérifie le mot de passe (<path>/sbin/unix_chkpwd</path>) doit être
étiqueté correctement afin que Sshd puisse transiter vers le contexte de
vérification du mot de passe. Ré-étiquetez PAM.
</p>

<pre caption="Réparer le contexte d'unix_chkpwd">
# <i>rlpkg pam</i>
</pre>

<p>
Le contexte du programme de vérification de mot de passe devrait maintenant
être <c>system_u:object_r:chkpwd_exec_t</c>. Essayez de vous reconnecter à
nouveau.
</p>

</body>
</subsection>
</section>

<section>
<title>Les contextes des fichiers de mots de passes sont incorrects</title>
<subsection>
<body>

<p>
Le fichier passwd (<path>/etc/passwd</path>) et shadow
(<path>/etc/shadow</path>) doivent être correctement étiquetés sinon PAM ne
pourra pas authentifier les utilisateurs. Ré-étiquetez les fichiers.
</p>

<pre caption="Réparer les contextes des fichiers de mots de passes">
# <i>restorecon /etc/passwd /etc/shadow</i>
</pre>

<p>
Leur contexte devraient maintenant être respectivement
<c>system_u:object_r:etc_t</c> et <c>system_u:object_r:shadow_t</c>. Essayez de
vous reconnecter à nouveau.
</p>

</body>
</subsection>
</section>

<section>
<title>Le contexte de Bash est incorrect</title>
<subsection>
<body>

<p>
Bash doit être correctement étiqueté afin que l'utilisateur puisse transiter
vers son domaine lors de la connexion. Ré-étiquetez bash.
</p>

<pre caption="Réparer le contexte de bash">
# <i>rlpkg bash</i>
</pre>

<p>
Bash (<path>/bin/bash</path>) doit maintenant avoir le contexte
<c>system_u:object_r:shell_exec_t</c>. Essayez de vous reconnecter à nouveau.
</p>

</body>
</subsection>
</section>

<section>
<title>Autres problèmes avec sshd</title>
<subsection>
<title>Validité du shell</title>
<body>

<p>
Premièrement, assurez-vous que le shell de l'utilisateur est valide.
</p>

<pre caption="Validité du shell">
# <i>grep</i> <comment>utilisateur</comment> <i>/etc/passwd | cut -d: -f7</i>
/bin/bash <comment>(Doit renvoyer le shell de l'utilisateur.)</comment>
</pre>

<p>
Si la commande précédente ne renvoie rien ou renvoie un shell incorrect,
redéfinissez le shell de cet utilisateur.
</p>

<pre caption="Définir le shell de l'utilisateur">
# <i>usermod -s /bin/bash</i> <comment>utilisateur</comment>
</pre>

</body>
</subsection>
<subsection>
<title>PAM activé</title>
<body>

<p>
PAM doit être activé dans sshd. Vérifiez que cette ligne soit bien décommentée
dans le fichier <path>/etc/ssh/sshd_config</path>&nbsp;:
</p>

<pre caption="Sshd doit utiliser PAM">
UsePAM yes
</pre>

<p>
SELinux ne permet actuellement qu'à PAM et à quelques rares autres programmes
d'accéder directement au fichier <path>/etc/shadow</path>. Openssh doit donc
utiliser PAM pour la vérification des mots de passes (cela ne concerne donc pas
l'accès par clé publique).
</p>

</body>
</subsection>
</section>
</sections>