Re: using set role command in a logon trigger -- got something implemented - now security question

At 09:05 AM 4/12/2007, laura pena wrote:
>Just to provide feedback here, I actually got this implemented using >the 10g feature creating application roles via schema packages. >Thanks for the link below Sriram.>>The user is configured to execute a schema package created as the >system user with AUTHID CURRENT_USER.>>The schema package uses sys_context to check the users environment >module name to determine which application is running. If it's the >"approved" module, permission to update,delete, insert into this >schema are granted via dbms_session.set_role to the logged in user.>>The application itself needed to modified to call this stored >procedure on login (it does more checks as well). All users allowed >to user this application configured to use this stored procedure.>>Works great. Except now I have a security question?>>Can a user spoof the sys_context environment module name ?>So say the user wants to have super privs within toad? Can he/she >change the module toad.exe to the module name of the application. >So they may have super privs to the applications tables now?

I am getting out on a limb here to say "most likely yes". How
difficult it is depends to some degree on how your sys_context
determines "the users environment module name".
If it's just from the program name that would be very easy to fake.
By just creating a copy of sqlplus as toad I get the following:
11:59:02 ora92.scott> exec print_table('select * from v$session where sid=9'

The program name is now toad.exe, but the module is still sql*plus
because sqlplus sets it via a call to
dbms_application_info.set_module. In order to change that I need to
intercept that and change the value to something else. Not at all
impossible to do. Just depends on the determination and knowledge of
the developer.