Bug 416891 - selinux is objecting to opening openoffice 2.3 after yum update
selinux is objecting to opening openoffice 2.3 after yum update
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
8
i686 Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-08 17:27 EST by Landon Kelsey
Modified: 2007-12-10 16:37 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-10 09:41:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Landon Kelsey 2007-12-08 17:27:32 EST
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:
Comment 1 Caolan McNamara 2007-12-08 18:57:27 EST
/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.
Comment 2 Landon Kelsey 2007-12-08 19:11:22 EST
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.
Comment 3 Daniel Walsh 2007-12-10 09:41:43 EST
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?
Comment 4 Bill Nottingham 2007-12-10 13:06:10 EST
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.
Comment 5 Daniel Walsh 2007-12-10 16:37:48 EST
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.