Hey didn't you use to work at WorldCom or Enron? :) Security people are trained to be nervous around holes. Will Johnson Fast Forward Technologies -----Original Message----- From: Bob Woodward <[EMAIL PROTECTED]> To: u2-users@listserver.u2ug.org Sent: Fri, 10 Jun 2005 14:44:02 -0700 Subject: RE: [U2] access via disabled accounts
Don't you folks think this is a bit of yelling "The sky is falling!"? I mean, who's going to produce a system that doesn't have audit trails, account verifications, or some other way of protecting against such illegal operations. Locks only keep honest people honest, and the same can be said of logins. This is an extreme example of what MIGHT happen but, again, how real is this threat? Maybe a documentation enhancement might be in order, but I don't see this as being something that IBM should have a finger shaken at them for. The person doing the criminal action is a crook and is risking jail time and probably will never working in the computer field again, once they are caught. Plan for being able to track what goes on and have a little faith that the people you hire to program around the "corporate jewels" are trustworthy. BobW > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of Martin Phillips > Sent: Thursday, June 09, 2005 9:14 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] access via disabled accounts > > > I'm not so sure I would call this a security hole. If I could figure > > it out, it might just be a security feature in that one could shut > > down access via UniObjects for users who have no business accessing > > the system that way. > > I go back to my original argument, perhaps explained more clearly (I hope) > this time.... > > Imagine you run a bank. Your employees log in each day from their desktop > PC > using a UniObjects based application and shuffle money about between > accounts. The application must have write access to the database files and > controls who can do what via its own internal security checks. > > A clever employee now writes a simple VB program that uses UniObjects and > puts it on his PC. This program connects to the server using his > username/password but, instead of calling the usual application modules, > uses UniObjects to open the files and transfer funds into his own account > totally outside the security of the application. > > Using any of the operating system or database security mechanisms shuts > out > the business application as well as the rogue user. > > The only way that I can see to close this hole is for UniObjects to have > an > option to restrict which operations the client end can request. At the > highest level, this should restrict the client so that all he can do is > call > existing catalogued programs that are compiled with some special compiler > mode directive. > > Come on... Someone convince me I'm wrong! > > > Martin Phillips > Ladybridge Systems > 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB > +44-(0)1604-709200 > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
