RE: Note to IBM... Wuz Re: Informix Warehouse Accelerator Prerequisites
Posted in 2011
Awww Fernado wants to play smurt IT Specialist... Junior, I have work to do and don't have time to play or lecture you. I think if you take the time to look up all that you can on Morris' worm you will understand the problems with .rhosts and hosts.equiv. Somehow I doubt you'd grok it in its completeness. I could lecture you on the economics of software development and putting a product out to market. Again, I doubt you have the business acumen to understand why IWA is a dead product. And while you mock Hadoop, its just now hitting mainstream. In fact, the irony is that many of IBM's core Informix customers are actually starting their own PoCs using Hadoop. (And not with IBM... ;-) Its a shame. Hadoop hits the high end but it doesn't replace the need for a solid RDBMs. Ironically XPS would be a good fit in this space, but hey! Remember Janet? Out of curiosity... ParAccel is this the new Informix? (Hint: Look at the history of a lot of their employees. ;-) But what do I know? Definitely more than I can say... -G Date: Mon, 22 Aug 2011 22:26:54 +0100 Subject: Re: Note to IBM... Wuz Re: Informix Warehouse Accelerator Prerequisites From: domusonline@gmail.com To: im_gumby@hotmail.com CC: informix-list@iiug.org On Mon, Aug 22, 2011 at 7:54 PM, Ian Michael Gumby <im_gumby@hotmail.com> wrote: Sigh. Ok junior, lets get a few things straight. I love when you call me junior. Not only reminds me that I'm still relatively young and away from the ages when some of us start to get messed up ideas, but more important is marks the point when you know you're not right. If you care for some advice, start to use it right on the first email... makes it less obvious. First, ever since Morris' worm, using .rhosts and /etc/hosts.equiv has been a very bad idea. Back in '88 one of my first tasks post Morris was to write a script that walked all of the user's home directories and report and log who had it, and then we deleted the file. Yes, its that serious. Use of /etc/hosts.equiv required a lot of forethought as to what went in and why. Two options here. Either you have time to waste, or you had rservices running. If the latest is true you couldn't be serious about security. The way Informix used it was never a good idea, considering that Turbo was the first and hit the market back in '90. Actually, the way Informix uses it is slightly better than rshell or rexec. The difference is not obvious to everyone, but having "hostname user" in /etc/hosts.equiv is completely different for Informix or rshell/rexec. But of course you know this and why. As you also know that you can turn off the functionality of using .rhosts and /etc/hosts.equiv in every Informix version. The point is, do you want to use trusted connections or not? If you don't, the problem never existed. If you want to use it but want central administration, deactivate the .rhosts lookup and use just /etc/hosts.equiv (again, if you don't have rservices, and you configure this, your fantastic script is a plain waste of time). The fact that it took 20 years to fix does in fact show that Informix and then IBM didn't care much about security. Yeah that's a pretty blatant slap in the face when it comes to Informix. The real problem with the fact that Informix used the same files as the rservices was for customers wanting to use rservices AND informix. Because granting access to Informix could mean you'd also grant access to the rservices and vice versa. On this point I totally agree with you and I was on the front of the list of the supporters. for that. But, again, rservices == no security. So this was not a big security problem. Customers worried with the security only used /etc/hosts.equiv and .rhosts for Informix. Naturally this was not correct or elegant. Actually the customers I know that care about this feature are relatively large shops where they obviously don't use rservices, but the fact that /etc/host.equiv is a "admin file" means the DBA must request changes to it. And this is a big inconvenience where the DBA has no root access. This does not bother the small shops where the "informix DBA" is normally the sys admin. At the same time, resource allocation is spend on fixing bugs or making enhancements based on what will get you the most bang for the buck. That's standard operating procedure for any company that is trying to stay afloat and make money. I don't have a problem with that. Its software development econ 101. What I do have a problem with is that whomever reviewed the list of bugs (this was one of them...) didn't assign it a high enough priority to get it the attention that it needed. Partially right: This was not a "bang for the buck" feature, because people with security concerns had not problem at all. And it was never truly a bug (AFAIK), but a feature request. It worked as design... Let me grant in advance that the design was broken :) Again, you seem to not comprehend the magnitude of the problem that .rhosts and hosts.equiv bring. You're right in today's internet, its a moot point. Why? Because *only* Informix took 20 years to stop using it. Also, because most modern applications (ODBC, .NET, J2EE etc.) don't use trusted connections, so you can deactivate the /etc/hosts.equiv and .rhosts lookup as I mentioned above. The only applications that may require it are 4GL and ESQL/C which programmers choose not use user/password authentication. But of course, you also know and agree with this, right senior? Look, unless you lived through the panic, the lessons learned don't carry the same weight. I haven't looked to see what's on Wikipedia about Morris' worm. If you understood what it did and how it did it, you wouldn't be having this conversation about telnetd. (Besides the whole unencrypted password thing, there were other issues that may or may not have been fixed.) Telnet had been replaced with more secure things like ssh. So I wonder how long it is before Informix err now IBM gets on the bandwagon and starts using SSH. ;-) Sure... More secure things. So secure that periodically you can find sshd vulnerabilities that allow for "script kids" like attacks. Don't confuse security "features" with real security. One thing is to allow telnet through the Internet. I wouldn't think about it for half a second. The other is install a secure sshd command that periodically appears in the security alerts with remote explotable security bugs. Some of them very similar to the original Sendmail bug used by Morris. Now... The problem is not using sshd. The problem is using ssh and think that it's enough to make you secure. On to your comments about IWA... IWA was designed to provide 'data warehouse' like capabilities to IDS. In fact it was billed and hyped as a 'big data' solution. Sure... A big data solution as long as the "big" data fits into the memory of a single node (currently). Could you point me to an official IBM document point IWA as a big data solution? (I did attend Carlton Doe's presentation until I got called away for some real work.) That's the problem with senior guys. They tend to mess up ideas when they think in more than one thing at a time. Of course how one define's 'Big Data' will help determine what products fall in to that category. And if you read my mini-rant, you'd understand that IWA doesn't scale. Hmmm