Bug 768312

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