Description of problem: SELinux is preventing /usr/bin/tshark from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that tshark should be allowed setsched access on processes labeled wireshark_t 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 'tshark' --raw | audit2allow -M my-tshark # semodule -X 300 -i my-tshark.pp Additional Information: Source Context staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 Target Context staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source tshark Source Path /usr/bin/tshark Port <Unknown> Host ci-vm-10-0-137-135.hosted.upshift.rdu2.redhat.com Source RPM Packages wireshark-cli-4.0.2-1.fc38.x86_64 Target RPM Packages SELinux Policy RPM selinux-policy-targeted-38.5-1.fc38.noarch Local Policy RPM selinux-policy-targeted-38.5-1.fc38.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name ci-vm-10-0-137-135.hosted.upshift.rdu2.redhat.com Platform Linux ci- vm-10-0-137-135.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 1 First Seen 2023-01-24 08:08:25 EST Last Seen 2023-01-24 08:08:25 EST Local ID 4fb949c3-798d-47f3-8412-13295b117018 Raw Audit Messages type=AVC msg=audit(1674565705.630:1076): avc: denied { setsched } for pid=3623 comm="tshark" scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=0 type=SYSCALL msg=audit(1674565705.630:1076): arch=x86_64 syscall=sched_setattr success=no exit=EACCES a0=e27 a1=563d074f9c70 a2=0 a3=60 items=0 ppid=3603 pid=3623 auid=1002 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002 sgid=1002 fsgid=1002 tty=pts0 ses=14 comm=tshark exe=/usr/bin/tshark subj=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 key=(null) ----------------------------- SELinux is preventing /usr/bin/tshark from using the execmem access on a process. ***** Plugin allow_execmem (91.4 confidence) suggests ********************* If this issue occurred during normal system operation. Then this alert could be a serious issue and your system could be compromised. Do contact your security administrator and report this issue ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that tshark should be allowed execmem access on processes labeled wireshark_t 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 'tshark' --raw | audit2allow -M my-tshark # semodule -X 300 -i my-tshark.pp Additional Information: Source Context staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 Target Context staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 Target Objects Unknown [ process ] Source tshark Source Path /usr/bin/tshark Port <Unknown> Host ci-vm-10-0-137-135.hosted.upshift.rdu2.redhat.com Source RPM Packages wireshark-cli-4.0.2-1.fc38.x86_64 Target RPM Packages SELinux Policy RPM selinux-policy-targeted-38.5-1.fc38.noarch Local Policy RPM selinux-policy-targeted-38.5-1.fc38.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name ci-vm-10-0-137-135.hosted.upshift.rdu2.redhat.com Platform Linux ci- vm-10-0-137-135.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 1 First Seen 2023-01-24 08:08:27 EST Last Seen 2023-01-24 08:08:27 EST Local ID 52ac150d-bf02-429d-81f6-31f3763b9249 Raw Audit Messages type=AVC msg=audit(1674565707.169:1079): avc: denied { execmem } for pid=3623 comm="tshark" scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=0 type=SYSCALL msg=audit(1674565707.169:1079): arch=x86_64 syscall=mmap success=no exit=EACCES a0=0 a1=10000 a2=7 a3=22 items=0 ppid=3603 pid=3623 auid=1002 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002 sgid=1002 fsgid=1002 tty=pts0 ses=14 comm=tshark exe=/usr/bin/tshark subj=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 key=(null)
Michale, These permissions seem not to have been required in previous releases. Are you aware of any changes? The denials can be split into 3 groups: 1. setresuid/setresgid syscalls ---- type=PROCTITLE msg=audit(01/24/2023 10:16:34.722:251) : proctitle=tshark type=SYSCALL msg=audit(01/24/2023 10:16:34.722:251) : arch=x86_64 syscall=setresgid success=yes exit=0 a0=root a1=root a2=root a3=0x5590e3a17940 items=0 ppid=725 pid=745 auid=staff uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=tshark exe=/usr/bin/tshark subj=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/24/2023 10:16:34.722:251) : avc: denied { setgid } for pid=745 comm=tshark capability=setgid scontext=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=capability permissive=0 ---- type=PROCTITLE msg=audit(01/24/2023 10:16:34.723:252) : proctitle=tshark type=SYSCALL msg=audit(01/24/2023 10:16:34.723:252) : arch=x86_64 syscall=setresuid success=yes exit=0 a0=root a1=root a2=root a3=0x5590e3a17940 items=0 ppid=725 pid=745 auid=staff uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=tshark exe=/usr/bin/tshark subj=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/24/2023 10:16:34.723:252) : avc: denied { setuid } for pid=745 comm=tshark capability=setuid scontext=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=capability permissive=0 ---- 2. sched_setattr ---- type=PROCTITLE msg=audit(01/24/2023 10:16:35.375:253) : proctitle=tshark type=SYSCALL msg=audit(01/24/2023 10:16:35.375:253) : arch=x86_64 syscall=sched_setattr success=no exit=EACCES(Permission denied) a0=0x2e9 a1=0x5590e3d4d8b0 a2=0x0 a3=0x60 items=0 ppid=725 pid=745 auid=staff uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=tshark exe=/usr/bin/tshark subj=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/24/2023 10:16:35.375:253) : avc: denied { setsched } for pid=745 comm=tshark scontext=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- 3. execmem ---- type=PROCTITLE msg=audit(01/24/2023 10:16:36.304:254) : proctitle=tshark type=SYSCALL msg=audit(01/24/2023 10:16:36.304:254) : arch=x86_64 syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x10000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0 ppid=725 pid=745 auid=staff uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=tshark exe=/usr/bin/tshark subj=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/24/2023 10:16:36.304:254) : avc: denied { execmem } for pid=745 comm=tshark scontext=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=0 Would tshark work properly if the execmem was dontaudited, i. e. not allowed, but not audited?
$ id uid=1001(sysadm-user) gid=1001(sysadm-user) groups=1001(sysadm-user),992(wireshark) context=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 $ The user executed 3 commands in enforcing mode and the following SELinux denials appeared: ---- type=PROCTITLE msg=audit(01/25/2023 07:15:27.930:637) : proctitle=tshark -D type=SYSCALL msg=audit(01/25/2023 07:15:27.930:637) : arch=x86_64 syscall=sched_setattr success=no exit=EACCES(Permission denied) a0=0x63c a1=0x55e563341320 a2=0x0 a3=0x60 items=0 ppid=1576 pid=1596 auid=sysadm-user uid=sysadm-user gid=sysadm-user euid=sysadm-user suid=sysadm-user fsuid=sysadm-user egid=sysadm-user sgid=sysadm-user fsgid=sysadm-user tty=pts1 ses=6 comm=tshark exe=/usr/bin/tshark subj=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/25/2023 07:15:27.930:637) : avc: denied { setsched } for pid=1596 comm=tshark scontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- type=PROCTITLE msg=audit(01/25/2023 07:15:42.710:638) : proctitle=tshark -L type=SYSCALL msg=audit(01/25/2023 07:15:42.710:638) : arch=x86_64 syscall=sched_setattr success=no exit=EACCES(Permission denied) a0=0x65d a1=0x55fee5581050 a2=0x0 a3=0x60 items=0 ppid=1576 pid=1629 auid=sysadm-user uid=sysadm-user gid=sysadm-user euid=sysadm-user suid=sysadm-user fsuid=sysadm-user egid=sysadm-user sgid=sysadm-user fsgid=sysadm-user tty=pts1 ses=6 comm=tshark exe=/usr/bin/tshark subj=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/25/2023 07:15:42.710:638) : avc: denied { setsched } for pid=1629 comm=tshark scontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- type=PROCTITLE msg=audit(01/25/2023 07:15:53.031:639) : proctitle=tshark -a duration:8 type=SYSCALL msg=audit(01/25/2023 07:15:53.031:639) : arch=x86_64 syscall=sched_setattr success=no exit=EACCES(Permission denied) a0=0x675 a1=0x562592327320 a2=0x0 a3=0x60 items=0 ppid=1576 pid=1653 auid=sysadm-user uid=sysadm-user gid=sysadm-user euid=sysadm-user suid=sysadm-user fsuid=sysadm-user egid=sysadm-user sgid=sysadm-user fsgid=sysadm-user tty=pts1 ses=6 comm=tshark exe=/usr/bin/tshark subj=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/25/2023 07:15:53.031:639) : avc: denied { setsched } for pid=1653 comm=tshark scontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- type=PROCTITLE msg=audit(01/25/2023 07:15:53.724:644) : proctitle=tshark -a duration:8 type=SYSCALL msg=audit(01/25/2023 07:15:53.724:644) : arch=x86_64 syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0 a1=0x10000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0 ppid=1576 pid=1653 auid=sysadm-user uid=sysadm-user gid=sysadm-user euid=sysadm-user suid=sysadm-user fsuid=sysadm-user egid=sysadm-user sgid=sysadm-user fsgid=sysadm-user tty=pts1 ses=6 comm=tshark exe=/usr/bin/tshark subj=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/25/2023 07:15:53.724:644) : avc: denied { execmem } for pid=1653 comm=tshark scontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- # rpm -qa selinux\* wire\* | sort selinux-policy-38.4-1.fc38.noarch selinux-policy-targeted-38.4-1.fc38.noarch wireshark-cli-4.0.2-1.fc38.x86_64 #
When the user executed the same 3 commands in permissive mode, the following SELinux denials appeared: ---- type=PROCTITLE msg=audit(01/25/2023 07:19:30.348:650) : proctitle=tshark -D type=SYSCALL msg=audit(01/25/2023 07:19:30.348:650) : arch=x86_64 syscall=sched_setattr success=yes exit=0 a0=0x6b7 a1=0x555db1a84320 a2=0x0 a3=0x60 items=0 ppid=1576 pid=1719 auid=sysadm-user uid=sysadm-user gid=sysadm-user euid=sysadm-user suid=sysadm-user fsuid=sysadm-user egid=sysadm-user sgid=sysadm-user fsgid=sysadm-user tty=pts1 ses=6 comm=tshark exe=/usr/bin/tshark subj=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/25/2023 07:19:30.348:650) : avc: denied { setsched } for pid=1719 comm=tshark scontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=1 ---- type=PROCTITLE msg=audit(01/25/2023 07:19:41.806:651) : proctitle=tshark -a duration:8 type=SYSCALL msg=audit(01/25/2023 07:19:41.806:651) : arch=x86_64 syscall=mmap success=yes exit=140704080146432 a0=0x0 a1=0x10000 a2=PROT_READ|PROT_WRITE|PROT_EXEC a3=MAP_PRIVATE|MAP_ANONYMOUS items=0 ppid=1576 pid=1762 auid=sysadm-user uid=sysadm-user gid=sysadm-user euid=sysadm-user suid=sysadm-user fsuid=sysadm-user egid=sysadm-user sgid=sysadm-user fsgid=sysadm-user tty=pts1 ses=6 comm=tshark exe=/usr/bin/tshark subj=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/25/2023 07:19:41.806:651) : avc: denied { execmem } for pid=1762 comm=tshark scontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=process permissive=1 ---- Please notice that the user belongs to the wireshark group. If the user does not belong to the wireshark group, the following message appears: tshark: Couldn't run /usr/bin/dumpcap in child process: Permission denied Are you a member of the 'wireshark' group? Try running 'usermod -a -G wireshark _your_username_' as root.
Hi Zdenek, I will try to figure out what is using these syscalls, give me some time, the wireshark code base is huge(I am keeping the needinfo). Btw. setsched is visible in ersion 3.4.10 which is currently in RHEL9. Regards, Michal
The setgid and setuid denials appear when the root user is confined (for example: sysadm_u) and executes the tshark command: ---- type=PROCTITLE msg=audit(01/25/2023 09:45:18.733:640) : proctitle=tshark -L type=SYSCALL msg=audit(01/25/2023 09:45:18.733:640) : arch=x86_64 syscall=setresgid success=yes exit=0 a0=root a1=root a2=root a3=0x559b72ed6940 items=0 ppid=1599 pid=1620 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=4 comm=tshark exe=/usr/bin/tshark subj=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/25/2023 09:45:18.733:640) : avc: denied { setgid } for pid=1620 comm=tshark capability=setgid scontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=capability permissive=0 ---- type=PROCTITLE msg=audit(01/25/2023 09:45:18.734:641) : proctitle=tshark -L type=SYSCALL msg=audit(01/25/2023 09:45:18.734:641) : arch=x86_64 syscall=setresuid success=yes exit=0 a0=root a1=root a2=root a3=0x559b72ed6940 items=0 ppid=1599 pid=1620 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=4 comm=tshark exe=/usr/bin/tshark subj=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(01/25/2023 09:45:18.734:641) : avc: denied { setuid } for pid=1620 comm=tshark capability=setuid scontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tcontext=sysadm_u:sysadm_r:wireshark_t:s0-s0:c0.c1023 tclass=capability permissive=0 ---- # id uid=0(root) gid=0(root) groups=0(root) context=sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 # tshark -L Running as user "root" and group "root". This could be dangerous. Data link types of interface eth0 (use option -y to set): EN10MB (Ethernet) DOCSIS (DOCSIS) #
I am adding the first part of the puzzle here, particularly the setsched syscall: This is caused by changes in the code since 3.x.x version of wireshark and it is because wireshark started using threads from glib. Take a look at this backtrace in gdb: #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007ffff01ef400 in g_system_thread_get_scheduler_settings ( scheduler_settings=0x7ffff02a9030 <shared_thread_scheduler_settings.lto_priv>) at ../glib/gthread-posix.c:1229 #2 g_thread_get_scheduler_settings (scheduler_settings=0x7ffff02a9030 <shared_thread_scheduler_settings.lto_priv>) at ../glib/gthread.c:945 #3 g_thread_pool_new_full (func=func@entry=0x55555556d550 <extcap_thread_callback>, user_data=user_data@entry=0x7fffffffd7d0, item_free_func=item_free_func@entry=0x0, max_threads=max_threads@entry=1, exclusive=exclusive@entry=0, error=error@entry=0x0) at ../glib/gthreadpool.c:646 #4 0x00007ffff01ef533 in g_thread_pool_new (func=func@entry=0x55555556d550 <extcap_thread_callback>, user_data=user_data@entry=0x7fffffffd7d0, max_threads=max_threads@entry=1, exclusive=exclusive@entry=0, error=error@entry=0x0) at ../glib/gthreadpool.c:564 #5 0x00005555555709fb in extcap_run_all (output_cb=0x55555556eb10 <extcap_list_interfaces_cb>, data_size=32, count=<synthetic pointer>, argv=0x7fffffffd7b0) at /usr/src/debug/wireshark-4.0.2-1.fc37.x86_64/extcap.c:487 #6 extcap_load_interface_list () at /usr/src/debug/wireshark-4.0.2-1.fc37.x86_64/extcap.c:2177 #7 0x00005555555662c5 in extcap_register_preferences () at /usr/src/debug/wireshark-4.0.2-1.fc37.x86_64/extcap.c:744 #8 extcap_register_preferences () at /usr/src/debug/wireshark-4.0.2-1.fc37.x86_64/extcap.c:731 #9 main (argc=<optimized out>, argv=0x7fffffffe318) at /usr/src/debug/wireshark-4.0.2-1.fc37.x86_64/tshark.c:1061 The sched_setattr syscall is actually coming from glib/gthread.c. Is this good enough reason for enabling the syscall for wireshark?
(In reply to Michal Ruprich from comment #9) > The sched_setattr syscall is actually coming from glib/gthread.c. Is this > good enough reason for enabling the syscall for wireshark? I have a counterquestion: what happens when the syscall is not enabled? The commands do not report any error and produce some output, I cannot confirm though if they get access to all required resources. $ tshark -L Data link types of interface ciscodump (use option -y to set): ciscodump (Remote capture dependent DLT) $ tshark -D 1. ciscodump (Cisco remote capture) 2. dpauxmon (DisplayPort AUX channel monitor capture) 3. sdjournal (systemd Journal Export) 4. sshdump (SSH remote capture) 5. udpdump (UDP Listener remote capture) 6. wifidump (Wi-Fi remote capture) In both cases the following trace is recorded: tshark 80652 [000] 188866.548030: avc:selinux_audited: requested=0x200 denied=0x200 audited=0x200 result=-13 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tclass=process ffffffff8360f01d avc_audit_post_callback+0x1ed ([kernel.kallsyms]) ffffffff8360f01d avc_audit_post_callback+0x1ed ([kernel.kallsyms]) ffffffff83632f68 common_lsm_audit+0x158 ([kernel.kallsyms]) ffffffff836100fe slow_avc_audit+0x9e ([kernel.kallsyms]) ffffffff836108fe avc_has_perm+0x13e ([kernel.kallsyms]) ffffffff8360cb9c security_task_setscheduler+0x2c ([kernel.kallsyms]) ffffffff8312c3ca __sched_setscheduler+0x5ba ([kernel.kallsyms]) ffffffff8312ca09 __do_sys_sched_setattr+0x159 ([kernel.kallsyms]) ffffffff83dd915b do_syscall_64+0x5b ([kernel.kallsyms]) ffffffff83e0009b entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms]) 10492d syscall+0x1d (/usr/lib64/libc.so.6) 853ff g_thread_pool_new_full+0x26f (/usr/lib64/libglib-2.0.so.0.7400.1) 1c9fa [unknown] (/usr/bin/tshark) 122c4 [unknown] (/usr/bin/tshark) 2750f __libc_start_call_main+0x7f (/usr/lib64/libc.so.6) 275c8 __libc_start_main_alias_2+0x88 (inlined) 167a4 [unknown] (/usr/bin/tshark) Similar question for execmem - is it necessary? Looks like the reason is using pcre2, but again I see no error: tshark 81241 [000] 189479.973633: avc:selinux_audited: requested=0x2000000 denied=0x2000000 audited=0x2000000 result=-13 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tclass=process ffffffff8360f01d avc_audit_post_callback+0x1ed ([kernel.kallsyms]) ffffffff8360f01d avc_audit_post_callback+0x1ed ([kernel.kallsyms]) ffffffff83632f68 common_lsm_audit+0x158 ([kernel.kallsyms]) ffffffff836100fe slow_avc_audit+0x9e ([kernel.kallsyms]) ffffffff836108fe avc_has_perm+0x13e ([kernel.kallsyms]) ffffffff83612090 file_map_prot_check+0x120 ([kernel.kallsyms]) ffffffff83612138 selinux_mmap_file+0x98 ([kernel.kallsyms]) ffffffff8360c09b security_mmap_file+0x7b ([kernel.kallsyms]) ffffffff832f7f6b vm_mmap_pgoff+0x5b ([kernel.kallsyms]) ffffffff83dd915b do_syscall_64+0x5b ([kernel.kallsyms]) ffffffff83e0009b entry_SYSCALL_64_after_hwframe+0x63 ([kernel.kallsyms]) 104ac7 __GI___mmap64+0x17 (inlined) 1d749 [unknown] (/usr/lib64/libpcre2-8.so.0.11.0) 4ea09 pcre2_jit_compile_8+0xf9 (/usr/lib64/libpcre2-8.so.0.11.0) 6bce0 [unknown] (/usr/lib64/libglib-2.0.so.0.7400.1) 6f510 g_regex_new+0x270 (/usr/lib64/libglib-2.0.so.0.7400.1) 288d1bf [unknown] (/usr/lib64/libwireshark.so.16.0.2) 72d3f g_slist_foreach+0x2f (/usr/lib64/libglib-2.0.so.0.7400.1) 22e5242 epan_new+0x132 (/usr/lib64/libwireshark.so.16.0.2) 319c9 [unknown] (/usr/bin/tshark) 15fec [unknown] (/usr/bin/tshark) 2750f __libc_start_call_main+0x7f (/usr/lib64/libc.so.6) 275c8 __libc_start_main_alias_2+0x88 (inlined) 167a4 [unknown] (/usr/bin/tshark)
Honestly I don't see any loss of function when these syscalls are blocked, it is hard to tell. Seems to me that the mmap calls are not just due to pcre2, I've found some again from glibc and others. I think we can leave them disabled for now and see whether someone hits a usecase where this limits what wireshark can do. How will this work? Do you want to add these syscalls as donotaudit so that there are at least no AVC messages in the log?
We will allow sched_setattr() and dontaudit execmem then. It is still unclear why there are the setresuid/setresgid syscalls when executed by UID 0: nothing seems to happen, the process still runs as 0/0. The same solution should be backported to RHEL 9.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Hi Zdenek, I think that wireshark is trying to drop as many privileges as possible but for some reason it calls setresgid and setresuid when started as root every time to set ruid, euid and suid to 0. This must happen even when root is not confined but we just don't see any AVC? Do I read the AVC correctly that when it says 'success=yes' then it means that the syscall was successful (returned 0) and the AVC is just sort of informative? The AVC is not there only when the root is unconfined(default right?). Not really sure about the logic behind this. Regards, Michal
(In reply to Michal Ruprich from comment #14) > Do I read the AVC correctly that > when it says 'success=yes' then it means that the syscall was successful > (returned 0) and the AVC is just sort of informative? Yes, the AVC is kind of bogus when the UIDs/GIDs match the ones already set. This is because currently the capability check happens before it is established if the new ids differ from the old ones. This could be fixed relatively easily in the kernel (by checking for no-op early and only testing for CAP_SET[UG]ID when it is actually changing something). Feel free to open a kernel BZ assigned to me for it so that I remember to send a fix upstream :)
Correction of my previous comment: the condition for when the capability is needed is not when it's a no-op, but rather when any of the ids to be set differs from the *id/e*id/s*id already set. Nonetheless, the bug is there and I submitted a patch to fix it: https://lore.kernel.org/selinux/20230215131807.293556-1-omosnace@redhat.com/
So this way(if this is fixed in kernel) even the confined root running wireshark will not generate AVC on setresuid/setresgid right?
If I understand the circumstances correctly, then yes. Definitely if a task with all the ids set to 0 calls setresuid()/setresgid() with all zeros it should then not check for the capabilities at all and thus not generate denials. If you want, I can scratch-build a kernel with the patch for testing.
Sure, if it isn't too much trouble, let's test this. Thanks.
Here you go: https://koji.fedoraproject.org/koji/taskinfo?taskID=97532338 (it will take a while to finish - kernel is a big package :)
Cool, thank you Ondra and Zdenek for your help. Once kernel builds I am going to give it a try.
Hm... it seems the kernel build is currently broken on rawhide :/ The latest official kernel build failed with the same error: https://koji.fedoraproject.org/koji/taskinfo?taskID=97533032 I think I'll give up for today and try again tomorrow if they fix in the meantime.
So I've submitted a PR as suggested in #c12. Any luck with the new kernel?
(In reply to Zdenek Pytela from comment #23) > Any luck with the new kernel? Oh, sorry, this slipped off my mind... I have started a new scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=98482431 It is for F38 (to get a more stable base kernel), but I think it should be installable also on Rawhide if needed. Let me know if a Rawhide-based kernel would be better.
So Ondra and I tested the kernel from comment #24 and no AVC related to tshark is shown when root is confined to sysadm_u:sysadm_r:sysadm_t.
Great, merging the selinux-policy PR.
FEDORA-2023-624eb88729 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-624eb88729
FEDORA-2023-624eb88729 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-624eb88729 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-9e48ecef73 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9e48ecef73 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-9e48ecef73 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.