Hide Forgot
Description of problem: I'm noticing the following AVC on every boot. Does colord need this capability? #============= colord_t ============== allow colord_t self:capability sys_admin; Here is the raw AVC: type=AVC msg=audit(1303995798.951:22): avc: denied { sys_admin } for pid=1161 comm="colord" capability=21 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tclass=capability type=SYSCALL msg=audit(1303995798.951:22): arch=c000003e syscall=2 success=yes exit=19 a0=7fffe330fc50 a1=802 a2=7fffe330fc58 a3=3 items=0 ppid=1 pid=1161 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="colord" exe="/usr/libexec/colord" subj=system_u:system_r:colord_t:s0-s0:c0.c1023 key=(null) and here is the output from sealert: SELinux is preventing /usr/libexec/colord from using the sys_admin capability. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that colord should have the sys_admin capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep colord /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:colord_t:s0-s0:c0.c1023 Target Context system_u:system_r:colord_t:s0-s0:c0.c1023 Target Objects Unknown [ capability ] Source colord Source Path /usr/libexec/colord Port <Unknown> Host tlondon.localhost.org Source RPM Packages colord-0.1.6-1.fc16 Target RPM Packages Policy RPM selinux-policy-3.9.16-15.fc16 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name tlondon.localhost.org Platform Linux tlondon.localhost.org 2.6.39-0.rc4.git2.0.fc16.x86_64 #1 SMP Thu Apr 21 02:24:19 UTC 2011 x86_64 x86_64 Alert Count 4 First Seen Wed 27 Apr 2011 06:37:56 AM PDT Last Seen Thu 28 Apr 2011 06:03:18 AM PDT Local ID 013dd854-645a-4b1c-9337-f5d186a96c4f Raw Audit Messages type=AVC msg=audit(1303995798.952:24): avc: denied { sys_admin } for pid=1161 comm="colord" capability=21 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tclass=capability type=SYSCALL msg=audit(1303995798.952:24): arch=x86_64 syscall=open success=yes exit=ENODEV a0=7fffe330fc50 a1=882 a2=5 a3=7fffe330e3b0 items=0 ppid=1 pid=1161 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=colord exe=/usr/libexec/colord subj=system_u:system_r:colord_t:s0-s0:c0.c1023 key=(null) Hash: colord,colord_t,colord_t,capability,sys_admin audit2allow #============= colord_t ============== allow colord_t self:capability sys_admin; audit2allow -R Version-Release number of selected component (if applicable): colord-0.1.6-1.fc16 How reproducible: Every boot Steps to Reproduce: 1. Boot 2. 3. Actual results: Expected results: Additional info:
What is 'sys_admin'? Thanks.
From previous BZ: https://bugzilla.redhat.com/show_bug.cgi?id=541217#c3 sys_admin is the catchall capability. Not really an SELinux thing. * Allow configuration of the secure attention key * Allow administration of the random device * Allow examination and configuration of disk quotas * Allow configuring the kernel's syslog (printk behaviour) * Allow setting the domainname * Allow setting the hostname * Allow calling bdflush() * Allow mount() and umount(), setting up new smb connection * Allow some autofs root ioctls * Allow nfsservctl * Allow VM86_REQUEST_IRQ * Allow to read/write pci config on alpha * Allow irix_prctl on mips (setstacksize) * Allow flushing all cache on m68k (sys_cacheflush) * Allow removing semaphores (Used instead of CAP_CHOWN to "chown" IPC message queues, semaphores and shared memory) * Allow locking/unlocking of shared memory segment * Allow turning swap on/off * Allow forged pids on socket credentials passing * Allow setting readahead and flushing buffers on block devices * Allow setting geometry in floppy driver * Allow turning DMA on/off in xd driver * Allow administration of md devices (mostly the above, but some extra ioctls) * Allow tuning the ide driver * Allow access to the nvram device * Allow administration of apm_bios, serial and bttv (TV) device * Allow manufacturer commands in isdn CAPI support driver * Allow reading non-standardized portions of pci configuration space * Allow DDI debug ioctl on sbpcd driver * Allow setting up serial ports * Allow sending raw qic-117 commands * Allow enabling/disabling tagged queuing on SCSI controllers and sending arbitrary SCSI commands * Allow setting encryption key on loopback filesystem * Allow setting zone reclaim policy
Is colord doing something with namespacing or mount?
(In reply to comment #3) > Is colord doing something with namespacing or mount? Nope. I can't see anything in sys_admin that colord is doing. Richard.
Maybe the kernel guys would have an idea?
Can you reproduce under strace? It might give us a better idea what file it is trying to open (and why that might require cap_sys_admin)
Or retry with a syscall filter enabled so we get a PATH record, e.g. /sbin/auditctl -w /etc/shadow -p w and then restart. The actual filter doesn't matter; there just needs to be at least one filter for the audit system to start collecting PATH information.
Tom could you do that on your machine all the time. I have -w /etc/shadow -p w in /etc/audit/audit.rules Which turns on full auditing, and will give you path information always.
Sure. I'll do so when I get back home later today. I'll then run the test and report back.
Here is what I see after adding '' to /etc/audit/audit.rules and then rebooting: type=AVC msg=audit(1304041886.295:24): avc: denied { sys_admin } for pid=1193 comm="colord" capability=21 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tclass=capability type=SYSCALL msg=audit(1304041886.295:24): arch=c000003e syscall=2 success=yes exit=19 a0=7fffee51bc80 a1=802 a2=7fffee51bc88 a3=3 items=1 ppid=1 pid=1193 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="colord" exe="/usr/libexec/colord" subj=system_u:system_r:colord_t:s0-s0:c0.c1023 key=(null) type=CWD msg=audit(1304041886.295:24): cwd="/" type=PATH msg=audit(1304041886.295:24): item=0 name="/dev/sg2" inode=7575 dev=00:05 mode=020660 ouid=0 ogid=6 rdev=15:02 obj=system_u:object_r:scsi_generic_device_t:s0 [The above was repeated 2 more times.] For completeness: [root@tlondon ~]# ls -l /dev/sg* crw-rw----. 1 root disk 21, 0 Apr 28 18:51 /dev/sg0 crw-rw----+ 1 root cdrom 21, 1 Apr 28 18:51 /dev/sg1 crw-rw----. 1 root disk 21, 2 Apr 28 18:51 /dev/sg2 [root@tlondon ~]# ls -lZ /dev/sg* crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg0 crw-rw----+ root cdrom system_u:object_r:scsi_generic_device_t:s0 /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg2 [root@tlondon ~]#
So if I unplug a FAT formatted SD card before I boot, this AVC goes away. Guessing that's what /dev/sg2 links to.
I guess we can dontaudit this for now and see if it causes any problems.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
colord is not loading profiles of other volumes now.