SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
* Access to raw memory: remove or make boolean?
@ 2020-02-24 15:11 Topi Miettinen
  2020-02-24 15:42 ` Russell Coker
  0 siblings, 1 reply; 5+ messages in thread
From: Topi Miettinen @ 2020-02-24 15:11 UTC (permalink / raw)
  To: selinux-refpolicy

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Access to raw memory: remove or make boolean?
  2020-02-24 15:11 Access to raw memory: remove or make boolean? Topi Miettinen
@ 2020-02-24 15:42 ` Russell Coker
  2020-02-24 15:56   ` Topi Miettinen
  0 siblings, 1 reply; 5+ messages in thread
From: Russell Coker @ 2020-02-24 15:42 UTC (permalink / raw)
  To: Topi Miettinen; +Cc: selinux-refpolicy

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/


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Access to raw memory: remove or make boolean?
  2020-02-24 15:42 ` Russell Coker
@ 2020-02-24 15:56   ` Topi Miettinen
  2020-02-25  0:27     ` Russell Coker
  0 siblings, 1 reply; 5+ messages in thread
From: Topi Miettinen @ 2020-02-24 15:56 UTC (permalink / raw)
  To: russell; +Cc: selinux-refpolicy

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Access to raw memory: remove or make boolean?
  2020-02-24 15:56   ` Topi Miettinen
@ 2020-02-25  0:27     ` Russell Coker
  2020-02-25  8:54       ` Topi Miettinen
  0 siblings, 1 reply; 5+ messages in thread
From: Russell Coker @ 2020-02-25  0:27 UTC (permalink / raw)
  To: Topi Miettinen; +Cc: selinux-refpolicy

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/


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Access to raw memory: remove or make boolean?
  2020-02-25  0:27     ` Russell Coker
@ 2020-02-25  8:54       ` Topi Miettinen
  0 siblings, 0 replies; 5+ messages in thread
From: Topi Miettinen @ 2020-02-25  8:54 UTC (permalink / raw)
  To: russell; +Cc: selinux-refpolicy

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-24 15:11 Access to raw memory: remove or make boolean? Topi Miettinen
2020-02-24 15:42 ` Russell Coker
2020-02-24 15:56   ` Topi Miettinen
2020-02-25  0:27     ` Russell Coker
2020-02-25  8:54       ` Topi Miettinen

SELinux-Refpolicy Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux-refpolicy/0 selinux-refpolicy/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux-refpolicy selinux-refpolicy/ https://lore.kernel.org/selinux-refpolicy \
		selinux-refpolicy@vger.kernel.org
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux-refpolicy


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git