SELinux is preventing systemd-readahe from 'write' accesses on the file /etc/abrt/abrt.conf. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that systemd-readahe should be allowed write access on the abrt.conf file 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 systemd-readahe /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:readahead_t:s0 Target Context system_u:object_r:abrt_etc_t:s0 Target Objects /etc/abrt/abrt.conf [ file ] Source systemd-readahe Source Path systemd-readahe Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages abrt-1.1.14-1.fc15 Policy RPM selinux-policy-3.9.12-6.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 2.6.37-2.fc15.i686 #1 SMP Fri Jan 7 15:46:20 UTC 2011 i686 i686 Alert Count 1 First Seen Fri 14 Jan 2011 08:49:17 AM EST Last Seen Fri 14 Jan 2011 08:49:17 AM EST Local ID 253b54ae-fa8e-4ca9-8b80-3578f891f86c Raw Audit Messages type=AVC msg=audit(1295012957.742:147): avc: denied { write } for pid=444 comm="systemd-readahe" path="/etc/abrt/abrt.conf" dev=dm-0 ino=18034 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=file Hash: systemd-readahe,readahead_t,abrt_etc_t,file,write audit2allow #============= readahead_t ============== allow readahead_t abrt_etc_t:file write; audit2allow -R #============= readahead_t ============== allow readahead_t abrt_etc_t:file write;
*** Bug 669685 has been marked as a duplicate of this bug. ***
*** Bug 669683 has been marked as a duplicate of this bug. ***
*** Bug 669681 has been marked as a duplicate of this bug. ***
*** Bug 669679 has been marked as a duplicate of this bug. ***
*** Bug 669677 has been marked as a duplicate of this bug. ***
*** Bug 669675 has been marked as a duplicate of this bug. ***
*** Bug 669673 has been marked as a duplicate of this bug. ***
*** Bug 669671 has been marked as a duplicate of this bug. ***
*** Bug 669670 has been marked as a duplicate of this bug. ***
*** Bug 669669 has been marked as a duplicate of this bug. ***
*** Bug 669668 has been marked as a duplicate of this bug. ***
Why is systemd trying to write to every file on the system, or at least checking access(X,W_OK) on every file.
satellit If you see lots of AVC's that look exactly the same, please do not report every single one. Make ours and your life easier by reporting one or two and then telling us you are seeing lots of others similar.
*** Bug 669931 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > Why is systemd trying to write to every file on the system, or at least > checking > > access(X,W_OK) on every file. Hmm, good question, I have no idea really. And looking through the sources I can't see where that could come from. Is there any way to figure out whether these AVCs got generated by the "systemd-readahead-collect" or by the "systemd-readahead-replay" tool? It would be really useful if those selinux reports could also include the argv[] array of the offending process, or at least argv[0] in addition to comm.
(btw, I think it would make sense to label systemd-readahead-replay differently from systemd-readahead-collect, as replay does not need any kind of write access to disk and collect needs only to write the final readahead data blob.)
What is really strange here is no one else has ever reported these and we have not seen this ourselves. satellit are you continuing to see these AVC when you boot? Lennart I looked through your code and did not see anything obvious either.
Actually Joachim Namislow saw this also.
We can turn on full auditing to get more data although I am not sure these AVC's since they happen so early in the boot would be affected. If anyone is continuing to see this, could you add -w /etc/shadow -p w to /etc/audit/audit.rules and reboot, then see if any better paths are showing up in the AVC messages.
This occurred on soas spin from nightly composes. (VMworkstation 6.5.2 booted from .iso) Booted to blank screen with pop up to report bugs (simple window manager?). Never got to sugar or gdm login. As only booting from .iso there is no way to edit and reboot.
I don't think these SELinux issues would have blocked anything. It might have been just a broken build. Are you seeing it on newer builds.
Hmm, Dan, so I have been seeing this now too. The process that triggers that is the readahead collector, which uses fanotify() to figure out what files are access during boot. My guess what might be going wrong here now is that the fds for the accessed files that fanotify() passes back to us are not properly handled by selinux on the kernel side: by calling read() on the fanotify fd we get one or more fds passed to us (yes, the semantics are weird like this), and my wild guess here is that the selinux checks for these fds don't properly take into account the file flags of these fds (i.e. the flags for these fds are configured a single time via fanotify_init() at very early start-up which can be much much earlier then when we actually get the fd. But then again, given that Eric wrote both fanotify and is an Selinux hacker this might be a completely wrong guess.
Ok lets reassign to kernel...
So, Eric tracked this down to the FS_IOC_FIEMAP ioctl which is considered a write access by SELinux although it really isn't. Patch 242631c49d4cf39642741d6627750151b058233b seems to be the culprit. Eric is working on a fix (i.e. revert).
*** Bug 671596 has been marked as a duplicate of this bug. ***
soas-x86_64-20110202.15.iso still throwing 39 bugs (local policy modules needed) starts in openbox (right click> logout get graphical Fedora release 15 (rawhide)logon for live System user which returns to openbox.
seeing this with Fedora 15 alpha release candidate. 50 occurences in one boot.
*** Bug 677763 has been marked as a duplicate of this bug. ***
The latest F15 policy has a dontaudit for this until the kernel is fixed.
BTW, this made LWN: http://lwn.net/Articles/428140/
So how would i use eparis' "audit_access" access vector to deal with these issues? I tried "dontaudit systemd_readahead_collect_t file_type:file audit_access;" but no go.
You can't. audit_access only applies when the check came from the access(2) syscall. In this case it came from the ioctl(2) syscall, so the only thing you can do it a normal dontaudit rule....
*** Bug 681127 has been marked as a duplicate of this bug. ***
*** Bug 682383 has been marked as a duplicate of this bug. ***
the problem still persist even if the system updated to selinux-policy-3.9.16-1.fc15.noarch selinux-policy-targeted-3.9.16-1.fc15.noarch
Yunustj please show us a couple of the AVC's you are seeing?
I still have 21 SElinux Alerts see Bug 681127 (mark duplicate above)
Raw Audit Messages type=AVC msg=audit(1299774390.577:22): avc: denied { write } for pid=561 comm="systemd-readahe" path="/etc/NetworkManager/VPN" dev=dm-1 ino=25463 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:NetworkManager_etc_t:s0 tclass=dir
Raw Audit Messages type=AVC msg=audit(1299774390.651:25): avc: denied { write } for pid=561 comm="systemd-readahe" path="/etc/cron.d" dev=dm-1 ino=25140 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:system_cron_spool_t:s0 tclass=dir
Raw Audit Messages type=AVC msg=audit(1299774390.713:27): avc: denied { write } for pid=561 comm="systemd-readahe" path="/var/spool/abrt" dev=dm-1 ino=17394 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir
Raw Audit Messages type=AVC msg=audit(1299774390.883:32): avc: denied { write } for pid=561 comm="systemd-readahe" path="/usr/share/cups/banners" dev=dm-1 ino=145520 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:cupsd_etc_t:s0 tclass=dir
Raw Audit Messages type=AVC msg=audit(1299774391.151:44): avc: denied { write } for pid=561 comm="systemd-readahe" path="/etc/sysconfig/network-scripts" dev=dm-1 ino=22079 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:net_conf_t:s0 tclass=dir
Raw Audit Messages type=AVC msg=audit(1299774432.185:97): avc: denied { read } for pid=1828 comm="mission-control" name=".mc_connections" dev=dm-3 ino=8913106 scontext=unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=AVC msg=audit(1299774432.185:97): avc: denied { open } for pid=1828 comm="mission-control" name=".mc_connections" dev=dm-3 ino=8913106 scontext=unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1299774432.185:97): arch=x86_64 syscall=open success=yes exit=EBADF a0=e88ca0 a1=0 a2=736e6f69746365 a3=2f65686361632e2f items=0 ppid=1827 pid=1828 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm=mission-control exe=/usr/libexec/mission-control-5 subj=unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 key=(null)
Raw Audit Messages type=AVC msg=audit(1299774395.980:81): avc: denied { write } for pid=561 comm="systemd-readahe" path="/etc/selinux/targeted/policy" dev=dm-1 ino=56854 scontext=system_u:system_r:readahead_t:s0 tcontext=system_u:object_r:semanage_store_t:s0 tclass=dir Please let me know if you required further information. You may want to guide me to provide them for you
Ok this is the rule we added, I guess we need to add dir. dontaudit readahead_t file_type : file { write audit_access } ;
The next selinux-policy for F15 will have this fix. Probably selinux-policy-3.9.16-3.fc15
The readaheads are different then the Munin one. That should be opened in a different bugzilla
(In reply to comment #46) > The next selinux-policy for F15 will have this fix. > > Probably selinux-policy-3.9.16-3.fc15 Just building.
Thank you Yes, It fix the problems with selinux-policy-targeted-3.9.16-3.fc15.noarch selinux-policy-3.9.16-3.fc15.noarch It remain Comment #43. Should this have its own bugzilla?