On Wednesday, 03/28/2018 at 02:19 GMT, Dimitri John Ledkov <[email protected]> wrote:
> Let me put this in a different perspective, as a millennial using a z > system for the first time less than 3 years ago... > > I was shocked when I discovered /proc/sysinfo on a z system, and that > even inside KVM machine it exposes the LPAR, z/VM, KVM information. > > And that this information is stored, is nested, and is passed through > to inner layers. I found it extremely insecure, as typically I expect > privilege separation after each layer of virtualization - as in a > public cloud guest user, should not be able to introspect the > underlying virtualisation middle layers (e.g. xen) or the bare metal. > > I expect a typical bare-metal -> virtualization -> containerization > deployment will not have the same sysadmin managing / supervising each > of those layers. I expect datacentre remote-hands sysadmin; devops; > developers to have segregated access to these things. > > However, after working with z systems a bit more, I realized that the > physical security and access modeling is very different. In effect, > one typically has a very limited number of people accessing the > mainframe, whilst sharing many hats. Hence the mindset that this is > sensitive information to expose from one context to a nested one is > simply not there. As someone who is focused on security (and networking and system management and DR and HA and documentation and performance and...), I assume that all non-CMS/GCS guests are compromised. Little containers of disease-carrying vermin they are. But it turns out that even without /proc/sysinfo the Linux guest can easily discover it's running on z/VM. It's part of z/Architecture to surface the execution container hierarchy. With that knowledge, it can start to probe it's immediate underlying hypervisor, looking for long-extant capabilities that, like Tide pods in the modern age, have been left within easy reach of the curious or mischievous. Other platforms have had incidents where a virtual machine has been able to drill a tunnel down through the floor into the hypervisor and up into a neighboring virtual machine. The good news is that's not a viable attack strategy on Z. The floor is too hard, having been under intense heat and pressure for half a century. It's like a diamond in that respect. But there are those aforementioned z/VM capabilities, the shiny facets of that diamond, that are permeable and need to be sealed away from the vermin. Folks who've attended my SHARE presentations on the subject have an awareness of some of the issues. Those who've engaged my z/VM security assessment services have a more thorough understanding of how to truly harden the z/VM system itself and other virtual machines against any hostile virtual machine. Natch, I'm not going to go open kimono on the details of that topic in public. Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 [email protected] IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
