Hi Martin You can lock down Universe so that a UniObjects developer cannot modify or delete files. Through creating SQL tables, you can set Modify, Update, Delete levels as you would have in an SQL environment. The issue is not that UniVerse cannot be secured, it is an issue for how far a user wants to lock down the environment. With the increased security of course comes increased administration cost.
Whilst security can always be improved, I do not believe we should rank U2 as an unsecured environment as this is not true. No matter what RDBMS you use, there are holes somewhere and they will never be completely locked down. In the end there has to be manual controls, methods and staffing policies. No security is impenetrable, it can only make thinks harder and increase the chance of offenders getting caught. David Jordan Managing Consultant [EMAIL PROTECTED] Mobile: 0428 669 730 DACONO Holdings Pty Ltd www.dacono.com.au PO Box 909 Lane Cove NSW 2066 Australia Phn: 61 2 9418 8320 Fax: 61 2 9427 2371 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Phillips Sent: Saturday, 17 December 2005 4:49 AM To: [email protected] Subject: Re: [U2] global catdir question - security hole I think that this goes back to the issue I tried to raise a couple of months back but failed to get much interest. Imagine that I have an employee who has a valid user name and password to use my uniObjects based application. He is a knowledgeable sort of chap who goes home and uses uniObjects to develop his own front end that he now installs on his PC in the workplace. His existing user name and password allow him to connect but, because he's got his own front end program, he now has freedom to do anything he wants because uniObjects allows him to open files, write records, execute programs and commands, etc. OK, you can say we should fix this with hiring practices. Is that a valid excuse under SOX when your system gets trashed or your commercially sensitive data is stolen? Or you could say that the user should not be able to install his own software on his PC. Yes, that's true but just how often are such rules actually enforced? The serious malicious user will usually find a way. Or you might argue that permissions should control this. Not true - The user will have the same rights as he has when he's in the real application and, as this thread pointed out, that allows him to replace programs in the catalogue opening the prospects of viruses and torjan horses, etc. Maybe I'm just being paranoid but I believe that the uniObjects interface opens a security hole that needs closing. Dare I say that in QM we addressed this in the equivalent interface by providing configurable options controlling what the client can do. In the strongest case we do not permit opening of files or execution of commands directly by the client, everything having to be done under the control of the server side application. Furthermore, we only allow the client to directly call subroutines that are compiled with a special option. Why can't uniObjects provide a similar level of security? Or have I missed something? Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
