VM security is one thing. VM security in practice is another. Historically, the vast majority of the ways to break into a VM system, were using openings that our shops opened in order to get valid work done.
I've been using VM since VM/370 Rel 6 BSE (back in the '70s for you youngsters). There are hundreds of things like the following: Backups. If you can't afford a CMS based backup product (after all, it is only used to back up a few percent of your disk space as the rest is for MVS, VSE and/or, now Linux), you can't really use DDR. Why? It uses PIOCS instead of LIOCS. No tape label processing. No TLMS support. So, what shop hasn't, at one time, used your guest OS to link to the full pack (starting at cyl 0) VM pack, and use your guest utility to do a full pack backup. Well, now, someone in your guest, can use Ditto or some other such product, to parse the pack for your directory information. Now I have the password for MAINT and now I have everything. You loaded the gun. You shot yourself in the foot. Poor practice...yes. Still done in some shops...yes A lot of people that are in charge of a VM system, don't know better. Sure, if you have a large shop, you may be able to afford a suite of VM based products AND a qualified VM Systems Programmer (min of 7-12 years experience). My guess, is most VM shops don't have that. And as the VM development group has done a great job of making the support of VM, less and less costly (and requiring less and less knowledge of VM), we produce more guns, and more feet <G>. And I, still, occasionally trip over something that....I'm just going to do for now....and never get back to... Ever get a tape drive attached to you and just read what ever is on the tape (yes, it is a scratch tape, but the data is still there). Many shops still depend on physical security.....in an Internet age.... Tom Duerbusch THD Consulting >>> Alan Altmark <[EMAIL PROTECTED]> 4/25/2007 10:17 AM >>> On Wednesday, 04/25/2007 at 09:31 EST, Adam Thornton <[EMAIL PROTECTED]> wrote: > The problem with that, is, of course, if you're class B, you pretty > much own the machine already anyway. A *much* more interesting hack > would have been class G to something useful, but no one I've talked > to can remember a VM exploit since at least the early 1980s that > allowed a Class G user to escape and compromise the hypervisor. If > anyone *does* know of a more recent privilege-escalation attack, I'd > be interested in hearing about it. The moment you give a user other than class G, you drill holes in the security/integrity walls, and expose your system to privilege escalation and audit bypass. Class A, B, and C are all very large drill bits. Class D can compromise data. Class E is a small diamond-tipped drill bit. Horses of different colors are located in the OPTIONS statement in the user directory. Unless a guest is part of your "trusted computing base" it should not have superuser status, special privilege classes or options in the directory. Alan Altmark z/VM Development IBM Endicott
