Description of problem: I am seeing the following AVCs from abrt accessing /var/lib/rpm/... : type=AVC msg=audit(1254239719.313:25): avc: denied { write } for pid=1422 comm="abrtd" name="rpm" dev=dm-0 ino=18 scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir type=SYSCALL msg=audit(1254239719.313:25): arch=c000003e syscall=21 success=yes exit=0 a0=13f5e80 a1=2 a2=0 a3=7fffaddd2b80 items=0 ppid=1 pid=1422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe="/usr/sbin/abrtd" subj=system_u:system_r:abrt_t:s0 key=(null) type=AVC msg=audit(1254239719.325:26): avc: denied { add_name } for pid=1422 comm="abrtd" name="__db.001" scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir type=AVC msg=audit(1254239719.325:26): avc: denied { create } for pid=1422 comm="abrtd" name="__db.001" scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file type=AVC msg=audit(1254239719.325:26): avc: denied { read write open } for pid=1422 comm="abrtd" name="__db.001" dev=dm-0 ino=5287 scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1254239719.325:26): arch=c000003e syscall=2 success=yes exit=0 a0=13f2b70 a1=c2 a2=1a4 a3=7fffaddd28d0 items=0 ppid=1 pid=1422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe="/usr/sbin/abrtd" subj=system_u:system_r:abrt_t:s0 key=(null) type=AVC msg=audit(1254239719.332:27): avc: denied { lock } for pid=1422 comm="abrtd" path="/var/lib/rpm/Packages" dev=dm-0 ino=23 scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1254239719.332:27): arch=c000003e syscall=72 success=yes exit=0 a0=7 a1=6 a2=7fffaddd2e30 a3=7fffaddd2b80 items=0 ppid=1 pid=1422 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe="/usr/sbin/abrtd" subj=system_u:system_r:abrt_t:s0 key=(null) Version-Release number of selected component (if applicable): abrt-debuginfo-0.0.9-2.fc12.x86_64 abrt-gui-0.0.9-2.fc12.x86_64 abrt-plugin-kerneloopsreporter-0.0.9-2.fc12.x86_64 abrt-plugin-mailx-0.0.9-2.fc12.x86_64 abrt-addon-ccpp-0.0.9-2.fc12.x86_64 abrt-addon-python-0.0.9-2.fc12.x86_64 abrt-desktop-0.0.9-2.fc12.x86_64 selinux-policy-targeted-3.6.32-11.fc12.noarch abrt-plugin-filetransfer-0.0.9-2.fc12.x86_64 abrt-libs-0.0.9-2.fc12.x86_64 selinux-policy-3.6.32-11.fc12.noarch abrt-plugin-bugzilla-0.0.9-2.fc12.x86_64 abrt-addon-kerneloops-0.0.9-2.fc12.x86_64 abrt-cli-0.0.9-2.fc12.x86_64 abrt-plugin-logger-0.0.9-2.fc12.x86_64 abrt-plugin-sqlite3-0.0.9-2.fc12.x86_64 abrt-plugin-runapp-0.0.9-2.fc12.x86_64 abrt-0.0.9-2.fc12.x86_64 abrt-devel-0.0.9-2.fc12.x86_64 How reproducible: Every time.... Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Why does abrt have to write file in /var/lib/rpm? I would like to lock down this domain as much as possible. I don't want it running rpm directly. I would rather have it only able to execute debuginfo-install and that is it. I do not have a problem with it running rpm to figure out what packages are installed. But if as a user I can get abrt to install stuff via crashing some apps, this concerns me.
Weird, as far as I know, abrt doesn't write anything directly to /var/lib/rpm, we use debuginfo-install for installing debuginfo rpms. We only use rpmlib directly to READ some info about package, certainly not for writing. rpmlib probably tries to create a lock file, but it should be allowed. Jirka
I don't think it does. When you use the rpm python bindings it does an access check to see if the database is writable, which is causing the problem. I have this dontaudited in selinux-policy-3.6.32-16.fc12.noarch