Description of problem: Trying to discover run a sendtargets discovery command, the iscsiadm returns 141. On dmesg: kernel: rx_data returned -13, expecting 48. kernel: iSCSI Login negotiation failed. Initially thought that it is a kernel issue, however when the rawhide/ark kernel is installed in el9 userland, the issue does not manifest. Version-Release number of selected component (if applicable): iscsi-initiator-utils-6.2.1.4-6.git2a8f9d8.fc37 targetcli-2.1.54-6.fc37 (same package versions work well on F37) kernel-6.2.0-0.rc3.20230113gitd9fc1511728c.28.fc38.x86_64 kernel-6.2.0-0.rc4.d368967cb103.35.test.eln.x86_64 (works on el9) How reproducible: 100% Steps to Reproduce: dnf install -y targetcli iscsi-initiator-utils targetcli /backstores/fileio create name=test file_or_dev=testfile size=1G targetcli iscsi/ create wwn=iqn.1994-05.com.redhat:lio targetcli iscsi/iqn.1994-05.com.redhat:lio/tpg1/ set attribute generate_node_acls=1 targetcli iscsi/iqn.1994-05.com.redhat:lio/tpg1/luns/ create /backstores/fileio/test iscsiadm -m discovery -t st -p 127.0.0.1 Actual results: login negotiation fail Expected results: target discovered successfully Additional info:
calling iscsiadm with debug option "-d 9" [...] iscsiadm: > IFMarker=No iscsiadm: > OFMarker=No iscsiadm: > ErrorRecoveryLevel=0 iscsiadm: > MaxRecvDataSegmentLength=32768 iscsiadm: wrote 48 bytes of PDU header so we are executing the function iscsi_io_send_pdu() header (48 bytes) has been sent, remaining has value = 280 so we have to send PDU data. note, however, that the kernel printed "rx_data returned -13, expecting 48." So the connection went down already? log_debug(4, "wrote %d bytes of PDU data", rc); has never been printed, no error messages too, so the userspace program must have been killed by a signal. strace indeed confirms it: writev(3, [{iov_base="InitiatorName=iqn.2016-04.com.op"..., iov_len=280}, {iov_base="", iov_len=0}], 2) = -1 EPIPE (Broken pipe) --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=35948, si_uid=0} --- +++ killed by SIGPIPE +++
In the kernel target driver, rx_data() calls sock_recvmsg(conn->sock, &msg, MSG_WAITALL); and the latter returns -13, which means EACCES (permission denied)
I can hit the bug with this very simple program, so it's not an iscsi-initiator bug http://bsdbackstore.eu/misc/target_kill/iscsitgtkiller.c # ./killiscsi -i iqn.2016-04.com.open-iscsi:9dc6359c6e4d -t iqn.2003-01.org.linux-iscsi.kvm-01-guest19.x8664:sn.6bb5209dd180 -p 127.0.0.1 [67625.987728] rx_data returned -13, expecting 48. [67625.988426] iSCSI Login negotiation failed. strace output: [...] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(3260), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 write(3, "C\207\0\0\0\0\1\342\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 532) = 532 write(3, "F\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48) = -1 EPIPE (Broken pipe)
After switching selinux to Permissive, the initiator is able to discover the target and login successfully.
With dontaudit disabled using `semodule -DB` I can see: type=AVC msg=audit(1674562240.219:628): avc: denied { read } for pid=1340 comm="iscsi_np" laddr=10.0.138.66 lport=3260 faddr=10.0.136.82 fport=37210 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0
# sealert -l "*" SELinux is preventing iscsi_np from read access on the tcp_socket port None. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that iscsi_np should be allowed read access on the port None tcp_socket 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: # ausearch -c 'iscsi_np' --raw | audit2allow -M my-iscsinp # semodule -X 300 -i my-iscsinp.pp Additional Information: Source Context system_u:system_r:kernel_t:s0 Target Context unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Target Objects port None [ tcp_socket ] Source iscsi_np Source Path iscsi_np Port <Unknown> Host ci-vm-10-0-138-66.hosted.upshift.rdu2.redhat.com Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-38.4-1.fc38.noarch Local Policy RPM selinux-policy-targeted-38.4-1.fc38.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name ci-vm-10-0-138-66.hosted.upshift.rdu2.redhat.com Platform Linux ci- vm-10-0-138-66.hosted.upshift.rdu2.redhat.com 6.2.0-0.rc3.20230113gitd9fc1511728c.28.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jan 13 16:09:20 UTC 2023 x86_64 Alert Count 18 First Seen 2023-01-24 07:17:30 EST Last Seen 2023-01-24 07:18:47 EST Local ID f57157f9-c00a-42d5-b345-7e96eaa59d23 Raw Audit Messages type=AVC msg=audit(1674562727.172:740): avc: denied { read } for pid=1340 comm="iscsi_np" laddr=10.0.138.66 lport=3260 faddr=10.0.136.82 fport=50940 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 Hash: iscsi_np,kernel_t,unconfined_t,tcp_socket,read --- Running audit2allow from this is not enough though, because then there is also: `Hash: iscsi_np,kernel_t,unconfined_t,tcp_socket,write` which needs to be allowed. After this it works as expected.
Caught in enforcing mode: ---- type=AVC msg=audit(01/24/2023 09:13:35.093:433) : avc: denied { read } for pid=3457 comm=iscsi_np laddr=127.0.0.1 lport=3260 faddr=127.0.0.1 fport=52254 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0 ---- Caught in permissive mode: ---- type=AVC msg=audit(01/24/2023 09:14:16.749:435) : avc: denied { read } for pid=3457 comm=iscsi_np laddr=127.0.0.1 lport=3260 faddr=127.0.0.1 fport=36296 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=1 ---- type=AVC msg=audit(01/24/2023 09:14:16.750:436) : avc: denied { write } for pid=3457 comm=iscsi_np laddr=127.0.0.1 lport=3260 faddr=127.0.0.1 fport=36296 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=1 ---- # rpm -qa selinux\* iscsi\* | sort iscsi-initiator-utils-6.2.1.4-6.git2a8f9d8.fc37.x86_64 iscsi-initiator-utils-iscsiuio-6.2.1.4-6.git2a8f9d8.fc37.x86_64 selinux-policy-38.5-1.fc38.noarch selinux-policy-targeted-38.5-1.fc38.noarch #
I was trying to run this down at this same time. It's certainly something in selinux-policy-38.5-1, as 38.4-1 and earlier work fine.
(In reply to Chris Leech from comment #8) > I was trying to run this down at this same time. > > It's certainly something in selinux-policy-38.5-1, as 38.4-1 and earlier > work fine. Chris, Can you doublecheck about the version? I believe there were no related changes in 38.5, but in 38.2 there were. It seems unusual only AVC type records were audited for these events. debugging info here: iscsi_np 1035 [000] 11154.878849: avc:selinux_audited: requested=0x4 denied=0x4 audited> ffffffffb873fdb7 avc_audit_post_callback+0x207 ([kernel.kallsyms]) ffffffffb873fdb7 avc_audit_post_callback+0x207 ([kernel.kallsyms]) ffffffffb876b20a common_lsm_audit+0x15a ([kernel.kallsyms]) ffffffffb8740c9e slow_avc_audit+0x9e ([kernel.kallsyms]) ffffffffb874167c avc_has_perm+0xac ([kernel.kallsyms]) ffffffffb874bbee selinux_socket_sendmsg+0xae ([kernel.kallsyms]) ffffffffb873dc87 security_socket_sendmsg+0x37 ([kernel.kallsyms]) ffffffffb8d300b5 sock_sendmsg+0x15 ([kernel.kallsyms]) ffffffffc0922181 tx_data+0x91 ([kernel.kallsyms]) ffffffffc0910879 iscsi_login_tx_data+0x59 ([kernel.kallsyms]) ffffffffc091a7f7 iscsit_put_login_tx+0x17 ([kernel.kallsyms]) ffffffffc0932e07 iscsi_target_locate_portal.cold+0x89 ([kernel.kallsyms]) ffffffffc091b47e iscsi_target_login_thread+0xa7e ([kernel.kallsyms]) ffffffffb813a942 kthread+0xf2 ([kernel.kallsyms]) ffffffffb8003139 ret_from_fork+0x29 ([kernel.kallsyms])
(In reply to Zdenek Pytela from comment #9) Hi Zdenek, it is indeed 38.2 for me. works on: selinux-policy-38.1-1.fc38.noarch selinux-policy-targeted-38.1-1.fc38.noarch reproduced on: selinux-policy-38.2-1.fc38.noarch selinux-policy-targeted-38.2-1.fc38.noarch
(In reply to Zdenek Pytela from comment #9) > (In reply to Chris Leech from comment #8) > > I was trying to run this down at this same time. > > > > It's certainly something in selinux-policy-38.5-1, as 38.4-1 and earlier > > work fine. > Chris, > > Can you doublecheck about the version? I believe there were no related > changes in 38.5, but in 38.2 there were. I'm not sure what was going on in my testing notes there, but 38.2 seems more correct. Anyway, verified that 38.6 is working now.