CryptoBox
Wednesday, May 19, 2004
Securing Miniframes
Miniframes, also known as Mini Computers, were a strange sort of adolencence between the mainframe era and the client/server PC-dominated era. Think late 1980s. I've suddenly got to learn a lot more about a couple of old miniframe platforms and how to secure them. Some systems are not even manufactured (hardware) or updated (OS/software) anymore. This means that some organizations run their ancient miniframe OS inside of some kind of virtual machine (harware emulation) living on top of Unix or something else "modern". In the case of what I've got to try and lock down the OS and the application (a database) are sort of a single entity. There is no TCP/IP stack, so CGIs (scripts) run locally on the "modern" OS and talk to the cleartext (not encrypted) files that make up the ancient OS/application. So Unix knows about the old OS, but not the inverse. Sort of like a person with two personalities where only one of them knows that it is not the only personality. So how to secure a system that keeps everything in cleartext and has no concept of the all-important trust boundary between applications and operating systems? Hmmm. Sounds a bit like the Windows NT family (at the heart of Win2k, WinXP, Win2003, etc.). Windows developers chose to put all graphical user interface (GUI) applications (just about everything) into the same memory space as the underlying OS's kernel uses. They did this so it would run faster, but this also means that marginally trustable applications like Outlook or something can execute code inside the same memory space as the most vital kernel modules. So an email virus can take over the entire OS without breaking a sweat. Perhaps I should think of this wierd miniframe OS/app on top of Unix as having the same level of vulnerability as Windows NT. No, I think this is different. In either case, if the root/admin account gets compromised, you're screwed. But what we're actually talking about here is data confidentiality and integrity, not kernel/OS integrity. Hmmm. Yes, I see it now: the trick here is to NOT see the virtual machine environment or even the obscurity of the miniframe OS/app. on top of it as providing any (or much) protection of the data. The files live inside Unix as ascii files. So they need to be protected in the same way as any other files on Unix. But we have to also secure the VM and OS/app parts too. Now I see which way to go. I need to segment the trust on the system almost as if it were an un-trusted network: data in one part of the network, processing in another, the client doing the querying, in another, with possibly malicious actors in-between. Sounds good, excpet I can't encrypt anything. Hmmm. Sort of reminds me of how Qmail was coded: none of the parts of qmail trust eachother, so, unlike other mail server software packages, qmail is only at v1.03 and has been there since 1998!
Comments:
As a humorous follow up: I'm having to ask around inside my company to find out if any of the old-folks who used to run the old miniframes are still around. I've heard that one expert is still around and hope to talk to him soon. There is scant documentation on the web about this stuff and the companies that manufactured and coded it are all out of business. I feel a bit like an archeologist or historian.
In the interest of full disclosure, some of the stuff I'm talking about in here (kernel boundaries, etc.) can be found in an excellent book called The Art of Unix Programming.
Post a Comment
