On Tuesday, 25 February 2020 2:56:01 AM AEDT Topi Miettinen wrote: > The PR would make all these conditional to new boolean, > allow_raw_memory_access. So if someone needs one of those many accesses (klogd_t or hald_t seems likely) then they also get access for things that aren't needed on most systems nowadays (EG xserver_t) and things that never made any sense (such as colord_t). I think it would be best to remove most of those /dev/mem access rules and add them back only after testing with recent software and comments about why they are needed. > > A quick grep of the latest policy turned up the above access to /dev/mem. > > Do ddcprobe_t, vbetool_t, and the X server still do that? mcelog_t, and > > klogd_t might have good uses, as might sosreport_t (don't even know what > > it does but guessing it's like klogd_t). rpm_t should maybe transition > > to a different domain for whatever it was doing and the same for kudzo_t. > > Vmware is a bit ugly, so vmware_t might actually do that. iscsi_t, > > mdadm_t, colord_t, and initrc_t should never have needed that. hald_t, > > hald_mac_t and > > devicekit_disk_t might have needed it, but hopefully that was fixed a long > > time ago. > > > > Interestingly bootloader_t doesn't have such access even though a quick > > inspection of the LILO source code shows that it still probes the boot > > order by directly reading the BIOS memory. I guess no-one uses LILO with > > SE Linux. > I also don't know most of these programs. Direct memory access was > probably needed for X server during SVGA times, at least NVIDIA driver > on my system does not seem to need it. I think it was needed before KMS. Is it even possible to run without KMS nowadays? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
