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.
-Topi Miettinen
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)
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.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
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
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/
On 25.2.2020 2.27, Russell Coker wrote:
> 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?
No idea. I'll update the PR so that only ddcprobe_t, vbetool_t,
mcelog_t, klogd_t, sosreport_t and vmware_t keep the access (subject to
boolean) and for others it's just removed unconditionally.
-Topi