illumos gate

When Jerry put this up four years ago, there was some relatively nebulous feedback that these devices should be accessible within zones some of the time under some special circumstances:

https://illumos.topicbox.com/groups/developer/Ta5eccab64a7acdd4

I think allowing these devices in zones is a poor choice, but I will add a single tunable to allow a reversion to the original behaviour in case there are folks stuck with this approach for some reason.

Testing Notes¶

First, confirming that MDB still works in the GZ:

root@oi0:~# truss -o /tmp/mdb.gz.out -t open mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba smbios fctl stmf stmf_sbd mm lofs random idm cpc sd crypto fcip fcp ufs logindmux nsmb ptm smbsrv nfs ]
> $q

root@oi0:~# grep '/dev/' /tmp/mdb.gz.out
open("/dev/ksyms", O_RDONLY)            = 4
open("/dev/ksyms", O_RDONLY)            = 4
open("/dev/ksyms", O_RDONLY)            = 4
open("/dev/kmem", O_RDONLY)         = 4
open("/dev/kmem", O_RDONLY)         = 4
open("/dev/mem", O_RDONLY)          = 5
open("/dev/ksyms", O_RDONLY)            = 6
open("/dev/ksyms", O_RDONLY)            = 6

Next, confirming that by default the device files are entirely missing
from a blank new zone:

root@oi0:~# zlogin testing
[Connected to zone 'testing' pts/3]
Last login: Thu Sep 24 22:28:00 on pts/3
The illumos Project rti-protection-rti-0-g2857728265    September 2020
root@testing:~# truss -o /tmp/mdb.ngz.out -t open mdb -k
mdb: failed to open /dev/ksyms: No such file or directory

Now, adding the devices to the zone and rebooting:

root@oi0:~# zonecfg -z testing
zonecfg:testing> add device
zonecfg:testing:device> set match=/dev/ksyms
zonecfg:testing:device> end
zonecfg:testing> add device
zonecfg:testing:device> set match=/dev/kmem
zonecfg:testing:device> end
zonecfg:testing> add device
zonecfg:testing:device> set match=/dev/mem
zonecfg:testing:device> end
zonecfg:testing> add device
zonecfg:testing:device> set match=/dev/allkmem
zonecfg:testing:device> end
zonecfg:testing>
zonecfg:testing> commit
zonecfg:testing>
root@oi0:~# zoneadm -z testing reboot

Checking that one cannot open the devices:

root@oi0:~# zlogin testing
[Connected to zone 'testing' pts/3]
Last login: Thu Sep 24 22:29:24 on pts/3
The illumos Project rti-protection-rti-0-g2857728265    September 2020
root@testing:~# truss -o /tmp/mdb.ngz.out -t open mdb -k
mdb: failed to open /dev/ksyms: Permission denied
root@testing:~# grep '/dev/' /tmp/mdb.ngz.out
open("/dev/ksyms", O_RDONLY)            Err#13 EACCES
root@testing:~# cat /dev/mem
cat: cannot open /dev/mem: Permission denied
root@testing:~# cat /dev/kmem
cat: cannot open /dev/kmem: Permission denied

Overriding the safety switch:

root@oi0:~# mdb -wke allow_unsafe_zone_access/W1
allow_unsafe_zone_access:       0               =       0x1

Witnessing the terror:

root@testing:~# open mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba smbios mm lofs random cpc sd crypto ufs logindmux nsmb ptm smbsrv nfs ]
> allow_unsafe_zone_access/X
allow_unsafe_zone_access:
allow_unsafe_zone_access:       1

Arresting the slide:

root@oi0:~# mdb -wke allow_unsafe_zone_access/W0
allow_unsafe_zone_access:       0x1             =       0x0

Back to normal:

root@testing:~# truss -o /tmp/mdb.ngz.out -t open mdb -k
mdb: failed to open /dev/ksyms: Permission denied
root@testing:~# grep '/dev/' /tmp/mdb.ngz.out
open("/dev/ksyms", O_RDONLY)            Err#13 EACCES

Checking that we can permanently engage danger mode:

root@oi0:~# echo 'set allow_unsafe_zone_access = 1' > /etc/system.d/mothermayi
root@oi0:~# reboot
reboot: Halting 1 zone.
reboot: Completing system halt.
updating /platform/i86pc/amd64/boot_archive (CPIO)

...

root@oi0:~# uptime
22:39:40    up 1 min(s),  1 user,  load average: 0.61, 0.17, 0.06
root@oi0:~# mdb -ke 'allow_unsafe_zone_access/X'
allow_unsafe_zone_access:
allow_unsafe_zone_access:       1

As I discovered while investigating #13120, there is a better way to do this: using the device policy mechanism to require the sys_devices privilege for these devices. I will retool this change in terms of that existing policy enforcement mechanism.