Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): selinux-policy-mls-3.7.19-118.el6.noarch selinux-policy-doc-3.7.19-118.el6.noarch selinux-policy-3.7.19-118.el6.noarch selinux-policy-targeted-3.7.19-118.el6.noarch selinux-policy-minimum-3.7.19-118.el6.noarch How reproducible: always Steps to Reproduce: 1. get a RHEL-6.2 machine 2. boot into runlevel 3 3. log in as root via console 4. switch to runlevel 5 (# init 5) which starts the GDM Actual results: ---- time->Tue Oct 25 11:26:32 2011 type=PATH msg=audit(1319534792.334:35095): item=0 name="/etc" inode=52 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 type=CWD msg=audit(1319534792.334:35095): cwd="/" type=SYSCALL msg=audit(1319534792.334:35095): arch=40000003 syscall=33 success=no exit=-13 a0=9945ec8 a1=2 a2=828ff4 a3=9945ec8 items=1 ppid=1 pid=2208 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gdm" exe="/bin/bash" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1319534792.334:35095): avc: denied { write } for pid=2208 comm="gdm" name="etc" dev=dm-0 ino=52 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=dir ---- Expected results: * no AVCs
Another (shorter) reproducer: 1. get a RHEL-6.2 machine 2. boot into runlevel 5 (which starts the GDM)
Is this a fresh install? I don't see this. Does everything work correctly?
I can think of no reason why gdm would want to write in a directory labeled etc_t
Is it possible that access() is called with wrong parameter ? ausearch -i says: ---- type=PATH msg=audit(10/25/2011 11:26:32.334:35095) : item=0 name=/etc inode=52 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:etc_t:s0 type=CWD msg=audit(10/25/2011 11:26:32.334:35095) : cwd=/ type=SYSCALL msg=audit(10/25/2011 11:26:32.334:35095) : arch=i386 syscall=access success=no exit=-13(Permission denied) a0=9945ec8 a1=2 a2=828ff4 a3=9945ec8 items=1 ppid=1 pid=2208 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=gdm exe=/bin/bash subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(10/25/2011 11:26:32.334:35095) : avc: denied { write } for pid=2208 comm=gdm name=etc dev=dm-0 ino=52 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=dir ----
Missed that. I guess we should dontaudit the access check. Kerberos libraries do wacky stuff like this. Miroslav I just checked in a fix for this in F16 policy.
files_dontaudit_access_check_etc(xdm_t)
Milos, good catch. We have this for usr_t. I am adding also this.
Read for snap 4. Milos, could you add qa_ack. Fixed in selinux-policy-3.7.19-119.el6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1511.html