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
I'm seeing this too. It happens every time my system receives one of those annoying ssh probes, making them infinitely more annoying.
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.
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 ***