Description of problem: We have transition rules to label /dev/bus/usb/XXX/YYY nodes appropriately with "usb_device_t". This is done in policy/modules/kernel/devices.if: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- filetrans_pattern($1, device_t, usb_device_t, chr_file, "000") filetrans_pattern($1, device_t, usb_device_t, chr_file, "001") filetrans_pattern($1, device_t, usb_device_t, chr_file, "002") : filetrans_pattern($1, device_t, usb_device_t, chr_file, "027") filetrans_pattern($1, device_t, usb_device_t, chr_file, "028") filetrans_pattern($1, device_t, usb_device_t, chr_file, "029") -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Unfortunately this hardcoded list is not sufficient, because some hardware devices are enumerated with numbers > 029, e.g.: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- $ grep 094 sos_commands/usb/lsusb Bus 001 Device 094: ID 0a5c:5842 Broadcom Corp. $ grep -w 94 sos_commands/usb/lsusb_-t |__ Port 10: Dev 94, If 0, Class=Application Specific Interface, Driver=, 480M |__ Port 10: Dev 94, If 1, Class=Chip/SmartCard, Driver=usbfs, 480M -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- We need hence to add more device names, ideally a regex should be used, but I doubt this is supported at all. Version-Release number of selected component (if applicable): selinux-policy-3.14.3-117.el8.noarch Also applies to RHEL9, from sources of the policy How reproducible: Always on customer system
Regular expressions are not supported in transitions yet in current kernels. These particular file transitions are quite troublesome since the path is not a part the definition, so can possibly affect other files in the /dev tree.
Renaud, Will it be possible to troubleshoot this case further? We'd like to know what are the udev events which pop when the devices are created: add, bind, some other, more of them at once, at which order? The udev service should run restorecon for each device created by kernel, but it may happen that this code path may be executed only for add events. I can't see any udev logs attached, so perhaps udevadm monitor can be used to gather the data.
From "udevadm monitor" output, the nodes udev is aware is /devices/... nodes, not /dev/bus/usb/xxx/yyy ones, explaining the issue. The latter nodes are directly created by the kernel driver (in customer's case it's the Broadcom device, running as "kernel_t").