Hide Forgot
Description of problem: Occurred on iSCSI target discovery during install from a live image (F22 Final TC3 Workstation x86_64). SELinux is preventing iscsid from 'read' accesses on the semaphore Unknown. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that iscsid should be allowed read access on the Unknown sem 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 iscsid /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:iscsid_t:s0 Target Context unconfined_u:system_r:install_t:s0-s0:c0.c1023 Target Objects Unknown [ sem ] Source iscsid Source Path iscsid Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-122.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.0.1-300.fc22.x86_64 #1 SMP Wed Apr 29 15:48:25 UTC 2015 x86_64 x86_64 Alert Count 1 First Seen 2015-05-12 18:39:27 EDT Last Seen 2015-05-12 18:39:27 EDT Local ID cdd078ff-5dc6-41d6-bbf2-8e92e391b336 Raw Audit Messages type=AVC msg=audit(1431470367.172:502): avc: denied { read } for pid=2358 comm="iscsid" key=167 scontext=system_u:system_r:iscsid_t:s0 tcontext=unconfined_u:system_r:install_t:s0-s0:c0.c1023 tclass=sem permissive=1 Hash: iscsid,iscsid_t,install_t,sem,read Version-Release number of selected component: selinux-policy-3.13.1-122.fc22.noarch Additional info: reporter: libreport-2.5.1 hashmarkername: setroubleshoot kernel: 4.0.1-300.fc22.x86_64 type: libreport
There are three other similar denials for different accesses: 'unix_read,unix_write', 'associate', and 'write'. Proposing as a freeze exception. There's a criterion "There must be no SELinux denial notifications or crash notifications on boot of or during installation from a release-blocking live image, or at first login after a default install of a release-blocking desktop.", but I think live install to an iSCSI target is sufficiently unusual to not really be a significant enough violation of the criterion, but FE seems appropriate.
install_t is a type for /usr/sbin/anaconda -- gen_context(system_u:object_r:install_exec_t,s0) /usr/bin/initial-setup -- gen_context(system_u:object_r:install_exec_t,s0) /usr/bin/ostree -- gen_context(system_u:object_r:install_exec_t,s0) /usr/bin/rpm-ostree -- gen_context(system_u:object_r:install_exec_t,s0) We would need to see what process runs as install_t. I don't think iscsid wants IPC with install_t. Adam, are you able to catch what process runs as install_t for this AVC?
It would be anaconda.
Ok it looks we will need to add a transition to iscsid_t.
Discussed at the 2015-05-14 blocker review meeting.[1] Voted as AcceptedFreezeException - it's good to fix AVCs encountered during installation (even with unusual hardware) [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-05-14
Clearing F22 accepted / nominated freeze exception status as F22 has shipped, per https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers . You may nominate as an Alpha, Beta or Final freeze exception for F23 if desired using the web application - https://qa.fedoraproject.org/blockerbugs/propose_bug (though it is not currently set up for F23) - or by marking the bug as blocking AlphaFreezeException, BetaFreezeException, or FinalFreezeException.
Should be already fixed.