Access to raw memory: remove or make boolean?

Access to raw memory: remove or make boolean?

[Topi Miettinen]

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

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

[Russell Coker]

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/

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

[Topi Miettinen]

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

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

[Russell Coker]

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/

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

[Topi Miettinen]

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