Oracle Security - Controlling the 'alter user' privilege

Question

Hi,
1. DB 10.1.0.5 and 10.2.0.3
2. "Admin User" needs to be able to change some users passwords in database.
3. Create user adminuser - grant alter user to adminuser.
4. DBAs will grant "approle" role to list of required users. DBAs will maintain control of who gets this role.
4. Create system trigger on alter database - will prevent "adminuser" from changing passwords for accounts not authorized - Script does not fire for DBAs and anyone changing their own password.
The trigger works as intended - the "adminuser" account can only change the specific set of users.
Question: We've discovered that the "adminuser" can also use the "alter user" privilege to change default tablespace and tablespace quota. User should only be able to change password.
Anyone have ideas on adding to the trigger to make sure the "adminuser" is only altering the password?
I am playing with the ora_is_alter_column system event, thinking that maybe the password column in user$ would be changed but so far I can't get this to work: Here is my trigger --
CREATE OR REPLACE TRIGGER SYS.PASSWORD_CONTROL AFTER ALTER ON DATABASE
DECLARE
DBACHK varchar2(50);
USRCHK varchar2(50);
BEGIN
BEGIN
-- Ensure users can change their own passwords --
IF
ora_login_user = ora_dict_obj_name
THEN
RETURN;
ELSE
-- Do not apply trigger to DBA group --
select grantee into DBACHK from dba_role_privs where granted_role='DBA'
and grantee = ora_login_user;
IF
DBACHK = ora_login_user
THEN
RETURN;
END IF;
END IF;
EXCEPTION
WHEN NO_DATA_FOUND
THEN
NULL;
END;
BEGIN
select grantee into USRCHK from dba_role_privs where
granted_role='DISCUSR' and grantee = ora_dict_obj_name;
IF
ora_dict_obj_type = 'USER'
and ora_dict_obj_name = USRCHK
---- Need to check that only the password is being change -- the line below does not work
and ora_is_alter_column('PASSWORD') = TRUE
THEN
RETURN;
ELSE
RAISE_APPLICATION_ERROR(-20003,
'You are not allowed to alter user.');
END IF;
EXCEPTION
WHEN NO_DATA_FOUND
THEN
RAISE_APPLICATION_ERROR(-20003,
'You are not allowed to alter user.');
END;
END;

Answer 1

user602453 wrote:
Ed, thank you for your reply. But, let me explain in more detail.
More detail is always helpful. ;-)
>
A specific user has been assigned as the application administrator. This admininstrator is responsible for reseting application user passwords. The DBA (me) recognizes the DB security issues so I am trying to craft a solution that will allow the application administrator the ability to change only the password of the application users.
I see that this may be out your hands, but I'd still question the wisdom of having an apps administrator being the one to change user passwords. Especially if that were a model where the users couldn't change their own passwords. I might accept it if the app admin were acting more of a helper to a clueless user.
Since the only way to change user passwords is to grant the 'alter user' privilege I need a system trigger to keep the user from changing non-application user passwords. Also, because I support nearly 100 production databases that support about 35 different applications I need a solution that can apply to multiple databases. I've been assured that there will only be one administrator charged with resetting passwords.
So,
Given those requirements, I have this trigger that will allow the the specific administrator to change the password of a specific set of user while not impacting DBAs or people wanting to change their own password. The way I've implemented this is to create a "dummy" role and assigning the role to the application user. The trigger will allow the administrator to change the password only if the user has the role assigned. The role has no privileges, it is just a way to "mark" the user as an application user. The administrator cannot grant this "dummy" role, only the DBA can.
Hope that clears things up.I still see another problem in that it still comes back to the dba to create the apps user in the first place, and to assign that dummy role to the user. Also, I'd hope that this proposed apps admin user is a role assigned to a real user. If not, as I mentioned before, you have no real accountability to who is using that account. Simply saying "it shall not be shared", even if written in corporate policy, won't secure it, and you won't be able to trace it. Well, you could turn on auditing and capture the OS userid in the audit log.