| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Discovered way to grant/revoke any right from any user!
A copy of this was sent to "Sybrand Bakker" <postbus_at_sybrandb.demon.nl>
(if that email address didn't require changing)
On Fri, 16 Apr 1999 19:27:29 +0200, you wrote:
>
> Wow...
> Is that a security loophole or is that a security loophole!
No, not really -- if you have the 2 very *POWERFULL* priveleges of create any procedure and execute any procedure, you can do *almost anything you want*.
> There are
> instances where this is very useful. In my current situation I'm a
> functional dba and the real techies are a bit reluctant to provide
> sufficient privilege permanently. I sympathize with them, I have always
> avoided to use the with admin option, I know this is a way to
> loose control.
> Two questions come to mind:
> I have seen a privilege called 'become user'. Yet I didn't see any command
> to accomplish that (except during imp of course). This seems to me a more
> legitimate way to address this. On some operating systems (Vax/VMS, Unix)
> this is working well. Does a similar command exist or is it in the 'next
> version'?
there is a new OCI feature in 8.1 whereby a user can grant someone else the ability to log in "on their behalf". That is, jane can allow tom to log in using toms userid and toms password but with an 'effecitive' userid of jane. tom can log in as jane without knowing janes password (but knowings toms password). the audit trail is aware of this and will audit correctly (jane performed operation X but it was really done by tom).
This feature is only in OCI (not supported by sqlplus, etc, etc) and is intended for 3 tier architectures where the client id's itself to the middle tier and the middle tier logs in as some known (to it) user on behalf of the person using the client tool. That way, the middle tier can 'log in for you'. For example, i might use an x509 certificate to authenticate to a webserver, the webserver gets my common name and uses that to log in with -- if the common name in the cert is a database user and that database user has said "its ok for the websever to do this", it'll work.
There is an undocumented oci function that does a real switch user in v7 and v8. It is used only by import to import. it is not released and i know of no plans to do so.
> The second question is quite obvious, and it is probably a
> feature request:
> couldn't we make sure Oracle closes this loophole in the near future.
>
You can already. don't use the DBA role (its documented that you should really make your own) with the least set of privs. Don't give it execute and procedure. It (that role) won't be able to do this. Don't forget, anyone with "alter user" can do the same quite easily.
I don't consider a loophole myself. execute any procedure is very powerful. create any procedure is perhaps less so (but does let me for example put 'trojan horse' code in place of real code so maybe it *is* extremely powerful). put the 2 together and you own the database. thats the DBA role. Anyone with DBA is *extremely* powerful.
> Best regards,
>
> Sybrand Bakker, Oracle DBA
> Thomas Kyte wrote in message <371a1585.9435998_at_192.86.155.100>...
> >A copy of this was sent to "Viewer" <bmotzer_at_spacestar.com>
> >(if that email address didn't require changing)
> >On Thu, 15 Apr 1999 23:11:53 -0500, you wrote:
> >
> [more snip]
> [snip]
> >
> >the import trick works because import silently 'becomes' the
> other user (in
> >effect, it is logging in as that other user for you).
> >
> >
> >there is an easier way to do this that works with 7.0 and up on all
> platforms in
> >sqlplus. If a user has "CREATE ANY PROCEDURE" and "EXECUTE ANY
> PROCEDURE"
> (eg:
> >a DBA), the following script works well:
> >[security bomb sniped, sorry]
> >SQL> @dogrant scott emp all public
> >
> >user is "TKYTE"
> >old 1: create procedure &1..dba_parse_$$( p_cur in number, p_str in
> varchar2 )
> >new 1: create procedure scott.dba_parse_$$( p_cur in number, p_str in
> varchar2
> >)
> >
> >Procedure created.
> >
> >old 2: where owner = upper('&1') and table_name = upper('&2')
> >new 2: where owner = upper('scott') and table_name = upper('emp')
> >
> >no rows selected
> >
> >old 6: sql_stmt := 'grant &3 on &1..&2 to &4';
> >new 6: sql_stmt := 'grant all on scott.emp to public';
> >old 7: &1..dba_parse_$$( exec_cursor, sql_stmt );
> >new 7: scott.dba_parse_$$( exec_cursor, sql_stmt );
> >
> >PL/SQL procedure successfully completed.
> >
> >old 2: where owner = upper('&1') and table_name = upper('&2')
> >new 2: where owner = upper('scott') and table_name = upper('emp')
> >that shows that it worked (the grants were in fact given) without logging
> in as
> >the other user.
> >
> >Thomas Kyte
> >tkyte_at_us.oracle.com
> >Oracle Service Industries
> >Reston, VA USA
> >
> >--
> >http://govt.us.oracle.com/ -- downloadable utilities
> >
> >-----------------------------------------------------------------
> ----------
> -
> >Opinions are mine and do not necessarily reflect those of Oracle
> Corporation
> >
>
>
>
>
Thomas Kyte
tkyte_at_us.oracle.com
Oracle Service Industries
Reston, VA USA
--
http://govt.us.oracle.com/ -- downloadable utilities
 |
 |