Bug 520345 - avc denied errors in audit.log
Summary: avc denied errors in audit.log
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node
Version: 6.0
Hardware: All
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: Fabian Deutsch
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 808368
Blocks: 855973 829023
TreeView+ depends on / blocked
 
Reported: 2009-08-31 01:35 UTC by Yufang Zhang
Modified: 2016-04-26 15:08 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-11 11:41:28 UTC


Attachments (Terms of Use)
Proposed patch. (710 bytes, patch)
2009-09-22 23:26 UTC, Alan Pevec
no flags Details | Diff
ovirt.log (64.75 KB, text/plain)
2009-09-27 09:13 UTC, Yufang Zhang
no flags Details
audit.log (40.13 KB, text/plain)
2009-09-27 09:16 UTC, Yufang Zhang
no flags Details
beta22.1 (24.77 KB, text/x-log)
2009-10-03 08:08 UTC, Qixiang Wan
no flags Details
/var/log/message [ beta22.1 install from usb] (74.04 KB, text/plain)
2009-10-03 12:31 UTC, Qixiang Wan
no flags Details
/var/log/ovirt.log [ beta22.1 install from usb ] (55.58 KB, text/plain)
2009-10-03 12:32 UTC, Qixiang Wan
no flags Details
/var/log/audit/audit.log [beta22.1 install from usb ] (64.53 KB, text/plain)
2009-10-03 12:33 UTC, Qixiang Wan
no flags Details

Description Yufang Zhang 2009-08-31 01:35:27 UTC
Description of problem:
After fresh install via usb onto disk,there are avc denied errors in audit.log. 

Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization Hypervisor release 5.4-2.0.99 (17)

How reproducible:
Always.

Steps to Reproduce:
1.Usb install to disk
2.After login to rhevh,
  #grep "avc:  denied" /var/log/audit/audit.log  
type=AVC msg=audit(1251658453.299:35): avc:  denied  { write } for  pid=7043 comm="domainname" path="pipe:[25735]" dev=pipefs ino=25735 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=fifo_file
type=AVC msg=audit(1251658453.299:35): avc:  denied  { write } for  pid=7043 comm="domainname" path="pipe:[25735]" dev=pipefs ino=25735 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=fifo_file

  
Actual results:


Expected results:


Additional info:
There are no influence on run-time with these errors.

Comment 2 Alan Pevec 2009-08-31 12:39:39 UTC
This should be added to in the selinux-policy, target context is correct here: initrc_t

Comment 4 Daniel Walsh 2009-08-31 14:45:17 UTC
This is a leaked file descriptor probably in the mkinitrd.

I doubt domainname is actually trying to write to a fifo file.

Make sure all of your open file descriptors to pipes are closed on exec.

fcntl(fd, F_SETFD, FD_CLOEXEC)

Comment 6 Alan Pevec 2009-09-22 23:07:38 UTC
We can avoid this by discarding stderr from network initscript, in ovirt-config-networking:
-    service network start
+    service network start 2> /dev/null

BTW pipe is coming from the redirection in ovirt-config-setup:
                    } 2>&1 | tee -a $OVIRT_TMP_LOGFILE;

Comment 7 Alan Pevec 2009-09-22 23:26:37 UTC
Created attachment 362150 [details]
Proposed patch.

Comment 8 Yufang Zhang 2009-09-27 09:13:38 UTC
Created attachment 362810 [details]
ovirt.log

QA tested this bug in beta 21.1,but still got avc denied error in audit.log:

#grep "avc:  denied" /var/log/audit/audit.log 
type=AVC msg=audit(1254041027.624:113): avc:  denied  { write } for  pid=6908 comm="domainname" path="pipe:[25462]" dev=pipefs ino=25462 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=fifo_file

Comment 9 Yufang Zhang 2009-09-27 09:16:17 UTC
Created attachment 362811 [details]
audit.log

Comment 11 Qixiang Wan 2009-10-03 08:05:54 UTC
AVC messages (same to comment 8) still exist in beta22.1:
...
/var/log/audit/audit.log:57:type=AVC msg=audit(1254554011.327:59): avc:  denied  { write } for  pid=6488 comm="domainname" path="pipe:[23114]" dev=pipefs ino=23114 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=fifo_file
...

Comment 12 Qixiang Wan 2009-10-03 08:08:26 UTC
Created attachment 363542 [details]
beta22.1

Comment 13 Perry Myers 2009-10-03 12:12:39 UTC
Can we have the other logs from the host that were generated with the avc.log?  (specifically /var/log/messages and ovirt.log)

Comment 14 Qixiang Wan 2009-10-03 12:31:16 UTC
Created attachment 363553 [details]
/var/log/message [ beta22.1 install from usb]

Comment 15 Qixiang Wan 2009-10-03 12:32:47 UTC
Created attachment 363554 [details]
/var/log/ovirt.log [ beta22.1 install from usb ]

Comment 16 Qixiang Wan 2009-10-03 12:33:49 UTC
Created attachment 363555 [details]
/var/log/audit/audit.log [beta22.1 install from usb ]

Comment 17 Qixiang Wan 2009-10-03 12:37:28 UTC
can also see the AVC message after cd-rom installation

Comment 21 RHEL Product and Program Management 2010-04-28 13:25:44 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 28 Alan Pevec 2011-09-16 10:23:25 UTC
In the latest build remaining avc denied on firstboot is:
avc:  denied  { write } for  pid=6732 comm="passwd" path=2F746D702F6666697870516C4837202864656C6574656429 dev=tmpfs ino=19924 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

admin     6677  6657  0 06:13 ttyS0    00:00:00 /bin/bash /usr/libexec/ovirt-admin-shell
root      6693  6677  0 06:13 ttyS0    00:00:00 sudo /usr/libexec/ovirt-config-setup
root      6694  6693  0 06:13 ttyS0    00:00:01 python /usr/libexec/ovirt-config-setup
root      6732  6694  0 06:13 ttyS0    00:00:00 [passwd] <defunct>

Comment 29 Alan Pevec 2011-09-16 10:37:57 UTC
> on firstboot
correction: on admin login

and on shutdown via o-c-setup:

avc:  denied  { read write } for  pid=10096 comm="shutdown" path=2F746D702F6666697870516C4837202864656C6574656429 dev=tmpfs ino=19924 scontext=unconfined_u:unconfined_r:shutdown_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
avc:  denied  { signal } for  pid=6657 comm="login" scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tclass=process
avc:  denied  { signal } for  pid=6657 comm="login" scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tclass=process

Comment 34 Guohua Ouyang 2012-02-20 03:00:19 UTC
Tested on 6.3-20120215 build, can still see avc denied message after a fresh install:

# grep denied /var/log/audit/audit.log 
type=AVC msg=audit(1329730891.175:44): avc:  denied  { read write } for  pid=8067 comm="shutdown" path=2F746D702F6666694E69716B3177202864656C6574656429 dev=tmpfs ino=20718 scontext=system_u:system_r:shutdown_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1329731741.723:26): avc:  denied  { write } for  pid=6588 comm="passwd" path=2F746D702F666669326D47754A4C202864656C6574656429 dev=tmpfs ino=21018 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1329731993.812:40): avc:  denied  { write } for  pid=6650 comm="passwd" path=2F746D702F666669326D47754A4C202864656C6574656429 dev=tmpfs ino=21018 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file

Comment 35 Fabian Deutsch 2012-06-04 13:49:00 UTC
I added rules (further below) to prevent the denials shown below, but they still appear:

type=AVC msg=audit(1338550824.782:54): avc:  denied  { write } for  pid=6692 comm="passwd" path=2F746D702F666669786566424F6D202864656C6574656429 dev=tmpfs ino=21267 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1338551157.787:68): avc:  denied  { append } for  pid=6773 comm="consoletype" path="/var/log/ovirt.log" dev=dm-3 ino=26 scontext=unconfined_u:system_r:consoletype_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1338551162.750:75): avc:  denied  { append } for  pid=6802 comm="consoletype" path="/var/log/ovirt.log" dev=dm-3 ino=26 scontext=unconfined_u:system_r:consoletype_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1338551330.319:20): avc:  denied  { write } for  pid=6643 comm="passwd" path=2F746D702F666669796A4F4D6B5A202864656C6574656429 dev=tmpfs ino=20739 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
type=AVC msg=audit(1338551412.265:46): avc:  denied  { append } for  pid=6683 comm="consoletype" path="/var/log/ovirt.log" dev=dm-3 ino=26 scontext=unconfined_u:system_r:consoletype_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1338551415.102:47): avc:  denied  { append } for  pid=6702 comm="consoletype" path="/var/log/ovirt.log" dev=dm-3 ino=26 scontext=unconfined_u:system_r:consoletype_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
 
--------------
 
…
    type var_log_t;
    type consoletype_t;
    class file { append mounton open getattr read execute ioctl lock entrypoint write };
…
allow consoletype_t var_log_t:file append;
allow passwd_t user_tmp_t:file write; 


(Complete set will follow as soon as vcs is available again)

Comment 36 Daniel Walsh 2012-06-04 13:51:16 UTC
 restorecon -R -v /var/log/ovirt.log
This looks like ovirt.log was created in /tmp and then mv'd to /var/log

Comment 37 Fabian Deutsch 2012-06-04 14:19:55 UTC
More details on the rules:

http://gerrit.ovirt.org/#/c/4209/3/recipe/ovirt16-post.ks

Comment 38 Fabian Deutsch 2012-06-04 14:55:53 UTC
The passwd problem can quite easily be reproduced by running e.g.

$ passwd -h

on the console.
What is the reason for the denial?

Comment 39 Daniel Walsh 2012-06-04 14:59:45 UTC
This sounds like your entire session has a leaked file descriptor to a file in /tmp.

ls -l /proc/self/fd
total 0
lrwx------. 1 root root 64 Jun  4 10:59 0 -> /dev/pts/0
lrwx------. 1 root root 64 Jun  4 10:59 1 -> /dev/pts/0
lrwx------. 1 root root 64 Jun  4 10:59 2 -> /dev/pts/0
lr-x------. 1 root root 64 Jun  4 10:59 3 -> /proc/624/fd

Comment 40 Fabian Deutsch 2012-06-04 15:45:40 UTC
Thanks Daniel,

and yes, after searching for it we (and other components) leak file descriptors.

Comment 42 Fabian Deutsch 2012-06-11 17:26:22 UTC
The following patch adds a wrapper around subprocess.Popen to close all open fds when spawning a child:
http://gerrit.ovirt.org/#/c/5241/

This is not everything, as we also rely on os.system which might also lead to problems.


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