Re: Access to raw memory: remove or make boolean?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24.2.2020 17.42, Russell Coker wrote:
On Tuesday, 25 February 2020 2:11:46 AM AEDT Topi Miettinen wrote:
Hi,

I made a PR 192 (https://github.com/SELinuxProject/refpolicy/pull/192)
for introducing a new boolean to disable access to raw memory devices
(/dev/mem, /dev/kmem, /dev/mergemem, dev/oldmem, /dev/port) because on
modern systems, direct access shouldn't be needed anymore. Chris
PeBenito asked to propose to this list whether instead of boolean, the
access should be removed unconditionally if it's no longer needed. I
think boolean could be useful for those systems where this is still
needed but still use latest reference policy.

https://lwn.net/Articles/147901/

A quick search turned up the above article from 2005 debating whether /dev/
kmem was of any use then.

./admin/ddcprobe.te:dev_read_raw_memory(ddcprobe_t)
./admin/ddcprobe.te:dev_wx_raw_memory(ddcprobe_t)
./admin/dmidecode.te:dev_read_raw_memory(dmidecode_t)
./admin/kudzu.te:dev_rx_raw_memory(kudzu_t)
./admin/kudzu.te:dev_wx_raw_memory(kudzu_t)
./admin/mcelog.te:dev_read_raw_memory(mcelog_t)
./admin/rpm.te:dev_read_raw_memory(rpm_t)
./admin/sosreport.te:dev_read_raw_memory(sosreport_t)
./admin/tboot.te:dev_read_raw_memory(txtstat_t)
./admin/vbetool.te:dev_wx_raw_memory(vbetool_t)
./admin/vbetool.te:dev_read_raw_memory(vbetool_t)
./apps/vmware.te:dev_read_raw_memory(vmware_t)
./apps/vmware.te:dev_write_raw_memory(vmware_t)
./services/hal.te:dev_read_raw_memory(hald_t)
./services/hal.te:dev_read_raw_memory(hald_mac_t)
./services/hal.te:dev_write_raw_memory(hald_mac_t)
./services/devicekit.te:        dev_read_raw_memory(devicekit_disk_t)
./services/colord.te:dev_read_raw_memory(colord_t)
./services/colord.te:dev_write_raw_memory(colord_t)
./services/xserver.te:dev_read_raw_memory(xserver_t)
./services/xserver.te:dev_wx_raw_memory(xserver_t)
./system/iscsi.te:dev_read_raw_memory(iscsid_t)
./system/iscsi.te:dev_write_raw_memory(iscsid_t)
./system/raid.te:dev_read_raw_memory(mdadm_t)
./system/init.te:       dev_rx_raw_memory(initrc_t)
./system/init.te:       dev_wx_raw_memory(initrc_t)
./system/logging.te:dev_read_raw_memory(klogd_t)

The PR would make all these conditional to new boolean, allow_raw_memory_access.

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.

-Topi



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux