Didnt mean to stir the 'stuff'. I do have my answer. Also, I believe we did try to give a privileged user rw and everyone else 'read' for catdir. Thankfully we tried it on our development machine, because the outcome was like a scene from 'war of the worlds'. j
On 12/19/05, Hona, David S <[EMAIL PROTECTED]> wrote: > Martin raised a good point. However, the problem is not the APIs itself > (all the APIs have this weakness), but how the U2 environment relies on > the underlying OS for user authentication and security. This is the > fundamental basic flaw of the U2 environment. > > Improve this and then you can build a better and more robust secure > environment. Perhaps including encrption and some form authentication > that the object hasn't been altered except by an internal command -- as > another level for critical system tables (such as the global catdir). > Obviously, putting all of these system critical files as SQL tables > would be a start. A radical departure from what is there now. But it's > what is required for today's environment. > > Such security enhancements need to include the logging of whom, what, > when and how any entity has connected to the U2 environment. All of > which is sadly lacking presently, again relying on the OS and "homebrew" > methods. > > As for the global catdir issue...there's an enhancement requested for > G23072 in U2TechConnect from 15 May 1998. It says: > > SHORT DESCRIPTION > Wants to remove the write permissions from catdir > > FULL DESCRIPTION > Customer would like to be able to remove the write permissions from the > programs in catdir. He would like to be able to only place certain users > in a unix group that would catalog programs. > > Regards, > David > > PS., There other "security holes" too. This isn't the only one out > there. Nor is it the worse one. > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, > Charles > Sent: Saturday, 17 December 2005 2:47 AM > To: [email protected] > Subject: RE: [U2] global catdir question - security hole > > > David Wolverton > > As a 'security risk', has IBM explicitly been asked to fix this item > > and said they'd prefer just to leave a gaping hole? > > Or is it like many things, everyone knows it, but everyone thinks > > someone else has followed up on it, and it must just be 'the way it > > must be'... Remember, IBM does not monitor this list for bugs to > > fix... At least, I'm not expecting them to! > > > > IBM seems to respond to TechConnect issues -- Log it! > > I first _formally_ reported it in 1996, although I can't prove that at > this point. I think there was a GTAR. > I have also had personal conversations about it with several > Vmark/Ardent/Informix/IBM people who were in a position to care or take > action. I remember asking about it in a question/answer panel during the > Ft. Lauderdale, 1998 national conference. So it has been a conscious > decision to leave it as is for about a decade. (When was UV first > implemented on NT? I do not remember how catdir's REF counter is > implemented there.) > > I cannot imagine I am the only one who has ever complained. It is a > glaring hole that everyone sees when they do the "ls -lt uv/catdir" that > John Reid mentioned at the top of this thread. Or everyone who wondered > how the &MAP&'s REF counter was incremented. > > I have not vigorously pursued it because those paying my bills, whose > DBs I would be protecting, have not cared enough. I don't think the > majority of companies worry about malicious attacks (from their own > staff or contractors). Even SJ+'s PRC, the premier U2 software control > tool, does not prevent malicious attempts to circumvent it. My own > UV/RCS-based SCM effort tightens things down pretty well, but I haven't > figure out how to protect catdir. I can only log changes to it. > > I'll take it to U2UG's Enhancement committee. > > cds > ------- > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > -- john ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
