Description of problem:just did a yum update and now I get the following when I
open openoffice (just updated)
Summary
SELinux is preventing /usr/sbin/sshd (sshd_t) "append" to <Unknown>
(var_log_t).
Detailed Description
SELinux is preventing /usr/sbin/sshd (sshd_t) "append" to <Unknown>
(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 (<Unknown>) 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 <Unknown>. If the file
context does not change from var_log_t, then this is probably a bug in
policy. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
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
You can attempt to fix file context by executing restorecon -v <Unknown>
The following command will allow this access:
restorecon <Unknown>
Additional Information
Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context system_u:object_r:var_log_t:s0
Target Objects None [ file ]
Affected RPM Packages openssh-server-4.7p1-4.fc8 [application]
Policy RPM selinux-policy-3.0.8-58.fc8
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.mislabeled_file
Host Name LMKIII
Platform Linux LMKIII 2.6.23.1-49.fc8 #1 SMP Thu Nov 8
21:41:26 EST 2007 i686 i686
Alert Count 78
First Seen Mon 03 Dec 2007 07:21:11 PM CST
Last Seen Mon 03 Dec 2007 07:26:17 PM CST
Local ID ca10f852-13a2-4122-a0f6-742b688c6d7b
Line Numbers
Raw Audit Messages
avc: denied { append } for comm=sshd dev=dm-0 egid=0 euid=0 exe=/usr/sbin/sshd
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=btmp pid=9839
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
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:

I have no idea where the openoffice came from. This looks more like an
setroubleshoot error.
As far as the btmp getting the wrong context on it. This seems to be some app is
removing and recreating the file in it's post install script without resetting
the file context. I have no idea why this would happen.
Bill do you have any idea who would modify this file?

Yes the only way this should happen is if, you had
rm /var/log/btmp
touch /var/log/btmp
Adding a
#[ -x /usr/bin/restorecon ] && restorecon /var/log/wtmp /var/run/utmp /var/log/btmp
Probably would not be a bad idea. Although I don't believe this is the problem.

Note

You need to
log in
before you can comment on or make changes to this bug.