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:
/usr/sbin/sshd can have nothing to do with OOo so is probably not OOo. Hard to know where the problem really is at this stage.
restorecon -v this did eliminate the problem I can start openoffice 2.3 without an SELINUX alert This has happened before and restorecon -v fixed the problem.
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?
initscripts.spec has: %post touch /var/log/wtmp /var/run/utmp /var/log/btmp chown root:utmp /var/log/wtmp /var/run/utmp /var/log/btmp chmod 664 /var/log/wtmp /var/run/utmp chmod 600 /var/log/btmp That should not actually change the context, though.
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.