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/
