When the service gpsd starts, it causes 4 entries in setroubleshoot that say gpsd was prevented from using the sys_admin capability. That seems overly broad so I'm not sure what it really needs. ausearch shows this: type=AVC msg=audit(1748535489.337:1429): avc: denied { sys_admin } for pid=250744 comm="gpsd" capability=21 scontext=system_u:system_r:gpsd_t:s0 tcontext=system_u:system_r:gpsd_t:s0 tclass=capability permissive=0 audit2allow generates this te file: module my-gpsd 1.0; require { type gpsd_t; class capability sys_admin; } #============= gpsd_t ============== allow gpsd_t self:capability sys_admin; This is what the unit file for gpsd looks like: # systemctl cat gpsd # /usr/lib/systemd/system/gpsd.service [Unit] Description=GPS (Global Positioning System) Daemon Requires=gpsd.socket 5:245m# Needed with chrony SOCK refclock After=chronyd.service 5:245m [Service] Type=forking EnvironmentFile=-/etc/default/gpsd EnvironmentFile=-/etc/sysconfig/gpsd ExecStart=/usr/bin/gpsd $GPSD_OPTIONS $OPTIONS $DEVICES 5:245m [Install] WantedBy=multi-user.target Also=gpsd.socket # /usr/lib/systemd/system/service.d/10-timeout-abort.conf 5:245m# This file is part of the systemd package. 5:245m# See https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer. 5:245m# 5:245m# To facilitate debugging when a service fails to stop cleanly, 5:245m# TimeoutStopFailureMode=abort is set to "crash" services that fail to stop in 5:245m# the time allotted. This will cause the service to be terminated with SIGABRT 5:245m# and a coredump to be generated. 5:245m# 5:245m# To undo this configuration change, create a mask file: 5:245m# sudo mkdir -p /etc/systemd/system/service.d 5:245m# sudo ln -sv /dev/null /etc/systemd/system/service.d/10-timeout-abort.conf 5:245m [Service] TimeoutStopFailureMode=abort And from gpsd's environ these 2 are set: OPTIONS=-n DEVICES=/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_FOBSb115818-if00-port0 Reproducible: Always Steps to Reproduce: 1. configure /etc/sysconfig/gpsd with the 2 env vars mentioned above 2. systemctl start gpsd 3. check setroubleshoot Actual Results: An selinux violation logged in setroubleshoot. Expected Results: No violation Additional Information: As far as I can tell gpsd is running ok. Not sure what selinux is preventing it from doing.
Hi, I cannot reproduce it, can you enable full auditing and restart the service? The sys_admin capability is too powerful so it requires justification. https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing Additional data may be needed: journalctl -u gpsd ls -lZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_FOBSb115818-if00-port0 ls -lLZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_FOBSb115818-if00-port0
Thanks for the quick follow up. Agreed that sys_admin just doesn't sound right. Here's the result from full auditing: type=PROCTITLE msg=audit(05/29/2025 10:19:02.282:1574) : proctitle=/usr/bin/gpsd -n /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_FOBSb115818-if00-port0 type=SYSCALL msg=audit(05/29/2025 10:19:02.282:1574) : arch=x86_64 syscall=setsockopt success=yes exit=0 a0=0xb a1=SOL_SOCKET a2=SO_ATTACH_FILTER a3=0x7ffd4efe2160 items=0 ppid=1 pid=260188 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=gpsd exe=/usr/bin/gpsd subj=system_u:system_r:gpsd_t:s0 key=(null) type=AVC msg=audit(05/29/2025 10:19:02.282:1574) : avc: denied { sys_admin } for pid=260188 comm=gpsd capability=sys_admin scontext=system_u:system_r:gpsd_t:s0 tcontext=system_u:system_r:gpsd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(05/29/2025 10:19:02.282:1574) : avc: denied { sys_admin } for pid=260188 comm=gpsd capability=sys_admin scontext=system_u:system_r:gpsd_t:s0 tcontext=system_u:system_r:gpsd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(05/29/2025 10:19:02.282:1574) : avc: denied { sys_admin } for pid=260188 comm=gpsd capability=sys_admin scontext=system_u:system_r:gpsd_t:s0 tcontext=system_u:system_r:gpsd_t:s0 tclass=capability permissive=0 type=AVC msg=audit(05/29/2025 10:19:02.282:1574) : avc: denied { sys_admin } for pid=260188 comm=gpsd capability=sys_admin scontext=system_u:system_r:gpsd_t:s0 tcontext=system_u:system_r:gpsd_t:s0 tclass=capability permissive=0 Something to do with gspd.socket? And additional data as requested: # journalctl -u gpsd --since "10 minutes ago" May 29 10:19:02 sydney.komacke.com systemd[1]: Stopping gpsd.service - GPS (Global Positioning System) Daemon... May 29 10:19:02 sydney.komacke.com systemd[1]: gpsd.service: Deactivated successfully. May 29 10:19:02 sydney.komacke.com systemd[1]: Stopped gpsd.service - GPS (Global Positioning System) Daemon. May 29 10:19:02 sydney.komacke.com systemd[1]: gpsd.service: Consumed 1min 25.042s CPU time, 1.6M memory peak. May 29 10:19:02 sydney.komacke.com systemd[1]: Starting gpsd.service - GPS (Global Positioning System) Daemon... May 29 10:19:02 sydney.komacke.com (gpsd)[260186]: 5:185m5:185mgpsd.service: Referenced but unset environment variable evaluate> May 29 10:19:02 sydney.komacke.com systemd[1]: Started gpsd.service - GPS (Global Positioning System) Daemon. That variable warning I believe is $GPSD_OPTIONS which is indeed unset. # ls -lZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_FOBSb115818-if00-port0 ls -lLZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_FOBSb115818-if00-port0 lrwxrwxrwx. 1 root root system_u:object_r:device_t:s0 13 May 28 07:57 /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_FOBSb115818-if00-port0 -> ../../ttyUSB0 crw-rw----. 1 root dialout system_u:object_r:usbtty_device_t:s0 188, 0 May 29 10:19 /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_FOBSb115818-if00-port0 and for good measure: # ls -lZ /dev/ttyUSB0 crw-rw----. 1 root dialout system_u:object_r:usbtty_device_t:s0 188, 0 May 29 10:19 /dev/ttyUSB0 [root@sydney ~]# ls -lLZ /dev/ttyUSB0
Interesting, thanks for the data. It looks like if the service wanted to attach a bpf filter, but then the bpf capability should be requested. Will you be able to install all needed debuginfos and gather stack trace? https://fedoraproject.org/wiki/SELinux/Debugging#Advanced_debugging https://fedoraproject.org/wiki/SELinux/Debugging#Using_perf_to_trace_all_system_denials
Created attachment 2092175 [details] perf.data file as requested
Well, I can only confirm it is setsockopt(), but I would need to have the same kernel and libraries to disclose the stack trace. Can you check if the service, despite the denial, works properly and efficiently when no local module is installed, allowing the capability?
Can you also confirm if there is a difference between kernel >=6.14.8 and <=6.14.6?
Interesting! Yes, it happens on 6.14.8 but does not happen on 6.14.5. What's going on there? As far as I can tell gpsd is running ok. Not sure what selinux is preventing it from doing. I've checked cgps and it seems normal. Also I've checked chronyc sources and it shows the gps being use as the reference.
I can only say that I don't know, a wild guess is something related to the capabilities check has changed, like order or maybe the attached filter now actually requires sys_admin. I need a kernel specialist to confirm this.
Ondrej, I guess we can now close this as a dup of bz#2369326, although the perf data only disclose setsockopt(). ffffffffba00012f [unknown] ([kernel.kallsyms]) 7f2ba80d590e __GI___setsockopt+0xe (/usr/lib64/libc.so.6) 7f2ba7f9d6c2 [unknown] (/usr/lib64/libudev.so.1.7.10) 7f2ba8351033 [unknown] (/usr/lib64/libusb-1.0.so.0.5.0) 7f2ba834f3bb libusb_init_context+0x67b (/usr/lib64/libusb-1.0.so.0.5.0)
Yes, this should be the same issue. It's likely more like this will be popping up... *** This bug has been marked as a duplicate of bug 2369326 ***