Hide Forgot
Description of problem: Login into CVS server causes AVC denial Version-Release number of selected component (if applicable): # rpm -qa | grep selinux libselinux-devel-2.0.94-5.2.el6.x86_64 selinux-policy-3.7.19-126.el6.noarch libselinux-2.0.94-5.2.el6.x86_64 libselinux-utils-2.0.94-5.2.el6.x86_64 selinux-policy-targeted-3.7.19-126.el6.noarch # cvs-1.11.23-11.el6_0.1.x86_64 How reproducible: deterministic Steps to Reproduce: 0. clear and fresh rhel62 machine 1. disable = no in /etc/xinetd.d/cvs 2. service xinetd restart 2. useradd petr && echo 1234 | passwd --stdin petr 3. cvs -d ":pserver:petr:1234.0.1:/var/cvs" login Actual results: cvs command pass: Logging in to :pserver:petr.0.1:2401/var/cvs but there is avc denial: type=AVC msg=audit(1324030525.407:86470): avc: denied { dac_override } for pid=2687 comm="cvs" capability=1 scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tclass=capability type=AVC msg=audit(1324030525.407:86470): avc: denied { dac_read_search } for pid=2687 comm="cvs" capability=2 scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tclass=capability Expected results: no denial Additional info:
This looks like you have a UID/Permission problem. Could you turn on full auditing. auditctl -w /etc/shadow -p w And then recreate this AVC, it will then contain a path to the file that is causing the problem.
I did `auditctl -w /etc/shadow -p w` then there is the same AVC, no path to any file, no inode: type=AVC msg=audit(1324037977.845:86614): avc: denied { dac_override } for pid=5399 comm="cvs" capability=1 scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tclass=capability type=AVC msg=audit(1324037977.845:86614): avc: denied { dac_read_search } for pid=5399 comm="cvs" capability=2 scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tclass=capability
err, sorry ignore Comment 2. there is more info during such an avc in /var/log/audit/audit.log: type=AVC msg=audit(1324038324.305:86623): avc: denied { dac_override } for pid=5410 comm="cvs" capability=1 scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tclass=capability type=AVC msg=audit(1324038324.305:86623): avc: denied { dac_read_search } for pid=5410 comm="cvs" capability=2 scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tclass=capability type=SYSCALL msg=audit(1324038324.305:86623): arch=c000003e syscall=2 success=no exit=-13 a0=7f93173006bb a1=80000 a2=1b6 a3=0 items=1 ppid=5362 pid=5410 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="cvs" exe="/usr/bin/cvs" subj=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) type=CWD msg=audit(1324038324.305:86623): cwd="/" type=PATH msg=audit(1324038324.305:86623): item=0 name="/etc/shadow" inode=1049715 dev=fd:00 mode=0100000 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shadow_t:s0 type=USER_AUTH msg=audit(1324038324.347:86624): user pid=5410 uid=0 auid=0 ses=2 subj=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="petr" exe="/usr/bin/cvs" hostname=? addr=? terminal=? res=success' type=USER_ACCT msg=audit(1324038324.352:86625): user pid=5410 uid=0 auid=0 ses=2 subj=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="petr" exe="/usr/bin/cvs" hostname=? addr=? terminal=? res=success' # ls -Z /usr/bin/cvs /etc/shadow ----------. root root system_u:object_r:shadow_t:s0 /etc/shadow -rwxr-xr-x. root root system_u:object_r:cvs_exec_t:s0 /usr/bin/cvs
Easy to reproduce.
If allow_cvs_read_shadow boolean is set to 1, these AVCs do not appear any more.
During the time I tried to reproduce the bug I came across another AVC. It appear when you try to add some file into the CVS repository. # mkdir /var/cvs/CVSROOT # date > pokus.txt # cvs -d ":pserver:randomuser:r4nd0m123.0.1:/var/cvs" add pokus.txt ---- time->Sat Dec 17 00:15:19 2011 type=SYSCALL msg=audit(1324098919.059:124738): arch=80000015 syscall=33 success=no exit=-13 a0=1003fbf29f0 a1=0 a2=0 a3=7fffffff items=0 ppid=30764 pid=30910 auid=0 uid=503 gid=506 euid=503 suid=503 fsuid=503 egid=506 sgid=506 fsgid=506 tty=(none) ses=7531 comm="cvs" exe="/usr/bin/cvs" subj=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1324098919.059:124738): avc: denied { search } for pid=30910 comm="cvs" name="randomuser" dev=sda2 ino=3075038 scontext=unconfined_u:system_r:cvs_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir ----
Yes, there is a boolean.
Closed by accident. The "search" AVC remains.
Interesting fact is that the AVC always contains "success=no" even if the reproducer ran in permissive mode.
I guess if the SYSCALL is failing for a reason outside of SELinux this could happen, such as DAC.
audit2allow -i /tmp/t1 #============= cvs_t ============== #!!!! This avc can be allowed using the boolean 'allow_cvs_read_shadow' allow cvs_t self:capability dac_override; allow cvs_t self:capability dac_read_search; Or setroubleshoot should have told us this fix was available.
*** Bug 773197 has been marked as a duplicate of this bug. ***
Maybe we should dontaudit this checks, since it probably will not work if you are not running the cvs daemon as root.
I agree. We don't audit it in RHEL5.
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-2012-0780.html