I've been trying to get Wireshark to work when run as by staff_u user. I've succeeded and want to report the necessary workarounds, hopefully policy can be updated so that they aren't necessary. Initially, wireshark simply segfaults. I can't get a backtrace out of GDB but the kernel messages reveal the segfault is form libQt6Gui.so.6.7.1: wireshark[226093]: segfault at 28 ip 00007f4f9f373264 sp 00007ffdb2ca0428 error 4 in libQt6Gui.so.6.7.1[173264,7f4f9f30e000+6cc000] likely on CPU 2 (core 0, socket 0) Code: 89 f0 c3 90 66 90 f3 0f 1e fa 48 8b 47 10 48 85 c0 74 04 48 8b 40 38 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa <48> 8b 47 10 48 85 c0 74 04 48 8b 40 38> The workaround is to enable the "domain_can_mmap_files" boolean. **This is probably a legit bug in Qt which I can file separately if you like.** However there are still lots of other AVCs. **They don't stop Wireshark from working** however it seems like they might affect accessibility, font rendering and theming, so perhaps it would be better to amend wireshark_t to allow them. I'll provide them & my analysis in 'additional information' below. As for getting capturing to work, this required other workarounds. Wireshark needs to be able to run /usr/bin/dumpcap, which uses file capabilties to gain cap_net_admin & cap_net_raw. You have to be in the wireshark group in order to this. I normally achieve this by running 'sudo -g wireshark wireshark' which runs it as my normal user but with 'wireshark' added to the process's supplementary groups. When running as a confined user, I tried 'sudo -g wireshark -r staff_r wireshark'. I added the -r option in order to override the default ROLE=sysadm_r that comes in via sudo. This resulted in a Wireshark window that was entirely black, and a dialog from GNOME Shell saying that the app is not responding. There are to workarounds to fix this: The first workaround was to add the following to the sudo command line: "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR XDG_SESSION_TYPE=$XDG_SESSION_TYPE" - I'm not sure exactly why, but I guess the presence of these variables causes Qt to avoid the problematic bit of code that causes it to freeze. The second workaround was to enable the boolean "xserver_clients_write_xshm" - with this, the environment variables are not needed, so I suppose Qt is retrieving the information it needs by using MIT-SHM instead in this case. I suppose it's worth considering whether there's much benefit of confining Wireshark to wireshark_t at all, since it breaks so much of the UI, but also doesn't actually prevent staff_t from capturing packets. I was a bit surprised that I didn't have to rely on a transition to staff_r in order to get dumpcap to work... Reproducible: Always Steps to Reproduce: 1. Create user mapped to staff_u 2. Log in (via gdm) 3. Run 'wireshark' Actual Results: $ gdb wireshark [...] Starting program: /usr/bin/wireshark warning: opening /proc/PID/mem file for lwp 253498.253498 failed: Permission denied (13) Failed to read a valid object file image from memory. [New LWP 253501] ** (wireshark:253498) 09:59:36.049269 [GUI WARNING] -- Session DBus not running. ** (wireshark:253498) 09:59:36.049313 [GUI WARNING] -- Application will not react to setting changes. Check your DBus installation. [New LWP 253502] [New LWP 253503] [New LWP 253504] [New LWP 253505] (wireshark:253498): Gdk-WARNING **: 09:59:36.056: Failed to load cursor theme Adwaita (wireshark:253498): Gdk-WARNING **: 09:59:36.114: Failed to load cursor theme Adwaita [New LWP 253506] [New LWP 253507] [New LWP 253508] [New LWP 253509] [New LWP 253510] [New LWP 253511] [New LWP 253512] [New LWP 253513] [New LWP 253514] [New LWP 253518] ** (wireshark:253498) 09:59:37.119907 [GUI WARNING] -- QWaylandShmBuffer: mmap failed (Permission denied) Thread 1 "wireshark" received signal SIGSEGV, Segmentation fault. 0x00007f745a373264 in ?? () Expected Results: No segfault. It's not clear whether staff_t should be allowed to use Wireshark but in any case it shouldn't crash. Here are the AVC events observed when running wireshark unprivileged (i.e., without using sudo to run it with the wireshark group added to its supplementary groups): ---- type=AVC msg=audit(11/06/24 09:59:35.986:21689) : avc: denied { write } for pid=253498 comm=QDBusConnection name=bus dev="tmpfs" ino=59 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0 ---- type=AVC msg=audit(11/06/24 09:59:36.052:21690) : avc: denied { getattr } for pid=253498 comm=wireshark path=/run/user/1673000001/bus dev="tmpfs" ino=59 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0 ---- type=AVC msg=audit(11/06/24 09:59:36.054:21691) : avc: denied { getattr } for pid=253498 comm=dconf worker path=/run/user/1673000001/bus dev="tmpfs" ino=59 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0 ---- type=AVC msg=audit(11/06/24 09:59:36.073:21693) : avc: denied { write } for pid=253498 comm=wireshark name=bus dev="tmpfs" ino=59 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0 ---- Those events relate to the user D-Bus: $ ls -i /run/user/$UID/bus 59 /run/user/1673000001/bus ---- type=AVC msg=audit(11/06/24 09:59:36.055:21692) : avc: denied { map } for pid=253498 comm=wireshark path=/memfd:wayland-cursor (deleted) dev="tmpfs" ino=276940 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:wireshark_tmpfs_t:s0 tclass=file permissive=0 ---- There are many events that match this one, I'll omit the others since there's so much duplication. This looks like https://bugzilla.redhat.com/show_bug.cgi?id=1943787 which was reported for gnome-shell around the Fedora 34 time. These are the events that prompted me to enable domain_can_mmap_files. ----- type=AVC msg=audit(11/06/24 09:59:36.120:21695) : avc: denied { write } for pid=253498 comm=QDBusConnection name=dbus-Pvm9duGa dev="dm-3" ino=1708609 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:cache_home_t:s0 tclass=sock_file permissive=0 ----- That one relates to I-Bus: $ find .cache -inum 1708609 .cache/ibus/dbus-Pvm9duGa ---- type=AVC msg=audit(11/06/24 09:59:36.175:21696) : avc: denied { map } for pid=253498 comm=wireshark path=/home/sam/.cache/fontconfig/157c1e8e759ec34dcd52ff4eb26ebd73-le64.cache-9 dev="dm-3" ino=1054197 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:user_fonts_cache_t:s0 tclass=file permissive=0 ---- There lots of of those, they also go away when domain_can_mmap_files is enabled. --- type=AVC msg=audit(11/06/24 09:59:36.341:21756) : avc: denied { getattr } for pid=253498 comm=wireshark path=/var/lib/flatpak/exports/share/icons/hicolor/index.theme dev="dm-1" ino=9035 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 ---- I guess it's looking for flatpak-installed icon themes? --- type=AVC msg=audit(11/06/24 09:59:37.035:21757) : avc: denied { read write } for pid=253498 comm=wireshark name=index dev="dm-3" ino=1048602 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:cache_home_t:s0 tclass=file permissive=0 ---- $ find -inum 1048602 ./.cache/mesa_shader_cache/index ---- type=AVC msg=audit(11/06/24 09:59:37.037:21758) : avc: denied { search } for pid=253498 comm=wireshark name=dev dev="proc" ino=2556628 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_dev_t:s0 tclass=dir permissive=0 ---- Something under /proc/sys/dev? Not sure, the inode number isn't found anywhere within /proc/sys. strace reveals a call to newfstatat on /proc/sys/dev/i915/perf_stream_paranoid which matches the target context, it's probably that. --- type-=AVC msg=audit(1718100212.723:23946): avc: denied { write } for pid=270363 comm="QXcbEventQueue" path=2F6D656D66643A786F7267202864656C6574656429 dev="tmpfs" ino=300358 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:xserver_tmpfs_t:s0 tclass=file permissive=0 ---- That's the message that lead me to enabling the xserver_clients_write_xshm boolean.
I don't think staff should have access to interfaces in promiscuous mode, but it should 1. start 2. read saved captures. Can you try the following module? # cat local_staff_wireshark.cil (allow wireshark_t cache_home_t (file (getattr map open read write))) (allow wireshark_t session_dbusd_tmp_t (sock_file (write))) (allow wireshark_t user_fonts_cache_t (file (map))) (allow wireshark_t wireshark_tmpfs_t (file (map))) (allow staff_t wireshark_tmpfs_t (file (map))) # semodule -i local_staff_wireshark.cil I also wonder what could be different in our systems setup since you keep getting slightly different denial than I do.
That module gets Wirehsark running (With both booleans disabled), thanks! It logs this (might have done before, and I overlooked it): (wireshark:461194): dbind-WARNING **: 09:10:57.999: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.AccessDenied: Sender is not authorized to send message Looks like it's caused by the accessibility bus denial. These denials are still logged: type=AVC msg=audit(1718352572.466:61988): avc: denied { getattr } for pid=460943 comm="wireshark" path="/run/user/1673000001/bus" dev="tmpfs" ino=59 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1718352572.467:61989): avc: denied { getattr } for pid=460943 comm=64636F6E6620776F726B6572 path="/run/user/1673000001/bus" dev="tmpfs" ino=59 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:session_dbusd_tmp_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1718352572.534:61990): avc: denied { write } for pid=460943 comm="QDBusConnection" name="dbus-Pvm9duGa" dev="dm-3" ino=1708609 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:cache_home_t:s0 tclass=sock_file permissive=0 type=AVC msg=audit(1718352572.607:61991): avc: denied { getattr } for pid=460943 comm="wireshark" path="/var/lib/flatpak/exports/share/icons/hicolor/index.theme" dev="dm-1" ino=9035 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0 type=AVC msg=audit(1718352573.088:61992): avc: denied { search } for pid=460943 comm="wireshark" name="dev" dev="proc" ino=5448798 scontext=staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_dev_t:s0 tclass=dir permissive=0 ... and the theme is still wrong - but I can open captures, click around the UI and it seems functional. It's still easy to get the black unresponsive window while the xserver_clients_write_xshm boolean is disabled. It's all down to combinations of environment variables - if the wrong combination of variables are set (which is what I originally hit with 'sudo -r staff_r -g wireshark wireshark', which removes _most_ of my environment variables, but passes through enough X11/Qt related variables that Qt is able to connect to the X server) then it looks like Qt hits a code path that tries to do something that's prevented by policy unless xserver_clients_write_xshm is enabled. I'm not familiar enough with the design of the policy to know whether this is something that should be enabled for most graphical users, or whether it's a bug in Qt, in that Qt fails to handle the failure of whatever operation is being denied by the policy. Finally, staff_t _can_ capture traffic which surprised me since 'sudo -r staff_r -u root tcpdump' and 'sudo -r staff_r -u root dumpcap' both fail with the same denial: avc: denied { create } for pid=466116 comm=tcpdump scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tclass=netlink_netfilter_socket permissive=0 ... but 'sudo -E -r staff_r -g wireshark wireshark' results in a Wireshark that's fully able to capture packets. > I also wonder what could be different in our systems setup since you keep getting slightly different denial than I do. The only customized permissive domain I have is staff_dbusd_t and the only booleans that are customized (according to semanage) are selinuxuser_tcp_server, which I enabled myself, and virt_sandbox_use_all_caps/virt_use_nfs which I don't remember enabling myself, but perhaps they were done by an RPM scriptlet. I can't think of any other customization I've done on this system, which is running Fedora 40 (which has been upgraded since around Fedora 30 time). If there's anything else you want me to check, let me know.
BTW here's the dumpcap that's launched by Wireshark: PID USER CONTEXT S TTY TIME COMMAND 467374 sam staff_u:staff_r:wireshark_t:s0-s0:c0.c1023 S pts/13 00:00:00 /usr/bin/dumpcap -S -Z none Looks like wireshark_t is allowed to gain the necessary capabilities: # sesearch -A -s wireshark_t -c capability allow wireshark_t wireshark_t:capability { net_admin net_raw }; ... and staff_t is allowed to run /usr/bin/wireshark which is has the type wireshark_exec_t.
Ok, with your policy and launching wireshark like so: "sudo -r staff_r -g wireshark XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR WAYLAND_DISPLAY=$WAYLAND_DISPLAY wireshark" - there are no AVC denials, the log message about AT-SPI is gone, and Wireshark looks normal. The black screen and need for xserver_clients_write_xshm are all caused by me inadvertently removing the environment variables that cause Qt to use Wayland; it fell back to X11 and that caused the remaining problems listed in comment 2. So, while I think Qt still shouldn't have crashed, at least we can say that the policy you've written is sufficient to get Wireshark working correctly.
FEDORA-2024-f30b2bffdc (selinux-policy-40.24-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f30b2bffdc
FEDORA-2024-f30b2bffdc has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f30b2bffdc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f30b2bffdc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-f30b2bffdc (selinux-policy-40.24-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
With the domain_can_mmap_files and xserver_clients_write_xshm booleans disabled, and without the custom policy you suggested, the following works: $ sudo -r sysadm_r -E -g wireshark wireshark Thank you! Without -E I still get the black screen - I'll file a report against Qt.