Bug 428500

Summary: SELinux is preventing sshd (sshd_t) "append" to (var_log_t)
Product: [Fedora] Fedora Reporter: Arnaud Mombrial <arnaud.mombrial>
Component: logrotateAssignee: Tomas Smetana <tsmetana>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: gustavo
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-15 06:52:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Arnaud Mombrial 2008-01-12 08:43:24 UTC
Detailed Description

ELinux is preventing sshd (sshd_t) "append" to (var_log_t). The SELinux type
var_log_t, is a generic type for all files in the directory and very few
processes (SELinux Domains) are allowed to write to this SELinux type. This type
of denial usual indicates a mislabeled file. By default a file created in a
directory has the gets the context of the parent directory, but SELinux policy
has rules about the creation of directories, that say if a process running in
one SELinux Domain (D1) creates a file in a directory with a particular SELinux
File Context (F1) the file gets a different File Context (F2). The policy
usually allows the SELinux Domain (D1) the ability to write, unlink, and append
on (F2). But if for some reason a file () was created with the wrong context,
this domain will be denied. The usual solution to this problem is to reset the
file context on the target file, restorecon -v . If the file context does not
change from var_log_t, then this is probably a bug in policy. Please file a bug
report against the selinux-policy package. If it does change, you can try your
application again to see if it works. The file context could have been
mislabeled by editing the file or moving the file from a different directory, if
the file keeps getting mislabeled, check the init scripts to see if they are
doing something to mislabel the file.

Allowing Access (Neither of these has any effect)

Vous pouvez essayer de corriger le contexte du fichier en exécutant restorecon
-v La commande suivante autorisera cet accès :restorecon 

Informations complémentaires
Contexte source:  system_u:system_r:sshd_t:SystemLow-SystemHigh
Contexte cible:  system_u:object_r:var_log_t
Objets du contexte:  None [ file ]
Paquetages RPM affectés:  openssh-server-4.7p1-4.fc8 [application]
Politique RPM:  selinux-policy-3.0.8-72.fc8
Selinux activé:  True
Type de politique:  targeted
MLS activé:  True
Mode strict:  Enforcing
Nom du plugin:  plugins.mislabeled_file
Nom de l'hôte:  real.mombrial.local
Plateforme:  Linux real.mombrial.local 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36
EST 2007 x86_64 x86_64
Compteur d'alertes:  4269
First Seen:  mer 02 jan 2008 12:04:34 CET
Last Seen:  sam 12 jan 2008 09:40:12 CET
Local ID:  241655a0-09d6-4f74-8a91-01d270566a3c
Numéros des lignes:  
Messages d'audit bruts :

avc: denied { append } for comm=sshd dev=md1 egid=0 euid=0 exe=/usr/sbin/sshd
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=btmp pid=21185
scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 sgid=0
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 suid=0 tclass=file
tcontext=system_u:object_r:var_log_t:s0 tty=(none) uid=0

Comment 1 Gustavo Maciel Dias Vieira 2008-01-13 01:04:09 UTC
I'm seeing this too. It happens every time my system receives one of those
annoying ssh probes, making them infinitely more annoying.


Comment 2 Daniel Walsh 2008-01-14 19:22:38 UTC
restorecon -R -v /var/log

Will fix.  This is caused by a bug in logrotate that is not preserving file
context.  I believe this is fixed in the updated logrotate.

Comment 3 Tomas Smetana 2008-01-15 06:52:52 UTC
The logrotate-3.7.6-2.1.fc8 should have this fixed (it's in the testing
repository and I marked it as stable already).  Note you have to run restorecon
anyway because the updated logrotate will preserve the context of the rotated
files so it must be right before rotating.  I mark this as duplicate of the
original bug.

*** This bug has been marked as a duplicate of 427274 ***