RE: Writing a "RPC Service"
Hi Michael The only thing I can think of is to restrict Access to Universe for this account, so that they cannot write, update or delete for this user group. Create Subroutines that have this access writes to write & Delete by using the Authorization statement in the code, which allows you to give the subroutine higher privilages than the user has running it. (It has to be compiled by a user with those privilages, so an unauthorised programmer cannot tamper with the subroutines) By this method, The programmer should be able to read, select, retrieve and call subroutines, through UniOPbjects or ODBC, and can only carry out writes and delete through Subroutines. I think is the easiest way to force this type of integrity on older systems, without resorting to SQLising the files. Hope this helps Regards David Jordan Managing Consultant [EMAIL PROTECTED] Dacono Holdings Pty Ltd Business & Technology Consulting PO Box 909 Lane Cove NSW 2066 Australia Ph 61 2 9418 8329 Fax 61 2 9427 2371 www.dacono.com.au -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael McRae Sent: Friday, 26 March 2004 5:30 PM To: [EMAIL PROTECTED] Subject: Writing a "RPC Service" A customer has asked how he could implement some stringent security on the 'unirpc' services. In particular, he wants to only allow certain 'Requests' (like the 'Subroutine' method, etc.) from any users out there writing UniVerse Objects front-ends. To me, this means he wants unirpc to fire off uvserver when requested by UniObjects, but to have uvserver only forward on his allowed Methods (and no other). This would keep developers from writing code that could .Read, .Write, .Delete, etc, and force them to obey his security standards. 1) The first option I can think is to 'intercept' the uvserver executable. Has anyone any experience with writing their own Services for unirpc? 2) Next, how about distributing a cut-down version of the DLL (or is it OCX?) that his users will bind into their app? Hoping there's a chance... Michael McRae -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Writing a "RPC Service"
[snip] A customer has asked how he could implement some stringent security on the 'unirpc' services. In particular, he wants to only allow certain 'Requests' (like the 'Subroutine' method, etc.) from any users out there writing UniVerse Objects front-ends. [snip] Overall, I think, like the others, that this isn't really a good idea. I don't have much time to think about this (therefore it is probably not going to work ;-) but what about trying to use permissions. Set all files (except what you absolutely need to gain access to the account) to not permit read/write/execute. In the subroutine, see if it's possible to 'su' to a user that does have the permission for file access. If this is possible, it now moves the security issue to another point, as this 'su' user is going to have the password available somewhere. And here is another crazy idea. Create an account with nothing in it (except what is minimally required). As part of your subroutines on the server, have them write out the file pointer (which is pointed to another account) to the VOC and then remove them when complete. You should keep the file pointer unique (so another process doesn't remove your pointer when it is done) and also keep it random (so that someone doesn't create a long process and then knowing the pointer, start operating on it). Of course, there is nothing to stop someone from opening the VOC from within UniObjects and writing their own pointer to the actual account/file so you would have to keep the actual filenames and real account path/name a secret. There are still ways to beat this so be careful. Finally, how about something to do with triggers (for writing anyway). Reject all writes unless they come from an acceptable routine. Again, these are not very good ideas, but, hey, it's Friday! Regards, Jim -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Writing a "RPC Service"
I use UOJ Not sure if the same approach can be done with Uniobjects. But an idea that jumps to mind is to provide your developers with a suite of classes other than the Uniobjects. In other words, put an abstract layer around uniobjects that provides just the functionality you are going to allow. Now, the only way you can prevent developers from utilizing the actual uniobjects is to perform some kind of code review, since anyone can get their hands on them. -Original Message- From: Michael McRae [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 1:30 AM To: [EMAIL PROTECTED] Subject: Writing a "RPC Service" A customer has asked how he could implement some stringent security on the 'unirpc' services. In particular, he wants to only allow certain 'Requests' (like the 'Subroutine' method, etc.) from any users out there writing UniVerse Objects front-ends. To me, this means he wants unirpc to fire off uvserver when requested by UniObjects, but to have uvserver only forward on his allowed Methods (and no other). This would keep developers from writing code that could .Read, .Write, .Delete, etc, and force them to obey his security standards. 1) The first option I can think is to 'intercept' the uvserver executable. Has anyone any experience with writing their own Services for unirpc? 2) Next, how about distributing a cut-down version of the DLL (or is it OCX?) that his users will bind into their app? Hoping there's a chance... Michael McRae -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Writing a "RPC Service"
Sounds like a pretty stupid idea to me. Shut down unirpc and write something else instead. Best option - buy redback and restrict access to the RBO designer. Then they can only use the objects and their properties published. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael McRae Sent: 26 March 2004 06:30 To: [EMAIL PROTECTED] Subject: Writing a "RPC Service" A customer has asked how he could implement some stringent security on the 'unirpc' services. In particular, he wants to only allow certain 'Requests' (like the 'Subroutine' method, etc.) from any users out there writing UniVerse Objects front-ends. To me, this means he wants unirpc to fire off uvserver when requested by UniObjects, but to have uvserver only forward on his allowed Methods (and no other). This would keep developers from writing code that could .Read, .Write, .Delete, etc, and force them to obey his security standards. 1) The first option I can think is to 'intercept' the uvserver executable. Has anyone any experience with writing their own Services for unirpc? 2) Next, how about distributing a cut-down version of the DLL (or is it OCX?) that his users will bind into their app? Hoping there's a chance... Michael McRae -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users This email was checked by MessageLabs SkyScan before entering Microgen. This email was checked on leaving Microgen for viruses, similar malicious code and inappropriate content by MessageLabs SkyScan. DISCLAIMER This email and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information. In the event of any technical difficulty with this email, please contact the sender or [EMAIL PROTECTED] Microgen Information Management Solutions http://www.microgen.co.uk -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Writing a "RPC Service"
This all sounds like an overkill. If you didn't want users / developers to do this, why would you want them to have access to the said server? I'm sure there is more to this, no? Furthermore, it would had overhead to the interface. Patching or intercepting calls to the UniRPC or servers it starts-up would be subject to "breaking" everytime IBM "improved" these interfaces. ;-) On the other hand, some sort of proxy-server/fire-wall software with "packet sniffing" (if such a beast exists) capabilities may work. Then again...overhead and likely to be broken by IBM, some time in the future. Perhaps he could consider turning all his accounts (or the ones he is most concerned about), into SQL Schemas (or just the files into SQL Tables)? Oh, of course maintaining SQL security on those isn't easy. But if they're serious about security, then you can't get more low-level or a per-user basis than that, at the UV database-level. Never tried it myself, but it could be a better and more economical solution. Next option, but don't bet on it coming soon...ask IBM to add this feature, to a future version of UV?!?! Regards David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael McRae Sent: Friday, March 26, 2004 5:30 PM To: [EMAIL PROTECTED] Subject: Writing a "RPC Service" A customer has asked how he could implement some stringent security on the 'unirpc' services. In particular, he wants to only allow certain 'Requests' (like the 'Subroutine' method, etc.) from any users out there writing UniVerse Objects front-ends. To me, this means he wants unirpc to fire off uvserver when requested by UniObjects, but to have uvserver only forward on his allowed Methods (and no other). This would keep developers from writing code that could .Read, .Write, .Delete, etc, and force them to obey his security standards. 1) The first option I can think is to 'intercept' the uvserver executable. Has anyone any experience with writing their own Services for unirpc? 2) Next, how about distributing a cut-down version of the DLL (or is it OCX?) that his users will bind into their app? Hoping there's a chance... Michael McRae -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
