* 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, other threads:[~2020-02-25 8:54 UTC | newest]
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).