I know that drop an object can cause to destroy a grant.
But what else can cause to lose a grant over an object?
Am asking that since I have to write some guidelines for the revs DB at work, I'd like to creae a list of operation where is necessary to also regenerate the grants for other schemas.
If also the user that grant access revoked access
you can look at this Question for more info :
Revoke Privileges in Oracle
Related
I granted the CREATE SESSION privilege to a recently created database user, and I granted him the SELECT privilege on some objects for different database schemas.
I find an apps schema (SCHEMA#) in v$session that is different from the database USERNAME recently created, and I would like to understand the phenomenon.
I think that he executes alter session set current schema and I would like to know if is it possible to revoke alter session privilege in Oracle 11g.
The documentation for the alter session statement says:
To enable and disable the SQL trace facility, you must have ALTER SESSION system privilege.
To enable or disable resumable space allocation, you must have the RESUMABLE system privilege.
You do not need any privileges to perform the other operations of this statement unless otherwise indicated.
As you don't need any privileges to perform alter session set current_schema, there is nothing you can revoke to prevent that being done. If you had actually granted alter session - which you haven't, from what you said - then you could of course still revoke that, but it would make no difference to the ability to change the current schema.
But this isn't really a problem, and is mentioned in the security guide as a good thing:
For example, a given schema might own the schema objects for a specific application. If application users have the privileges to do so, then they can connect to the database using typical database user names and use the application and the corresponding objects. However, no user can connect to the database using the schema set up for the application. This configuration prevents access to the associated objects through the schema, and provides another layer of protection for schema objects. In this case, the application could issue an ALTER SESSION SET CURRENT_SCHEMA statement to connect the user to the correct application schema.
Your recently-created user does not have any additional privileges or abilities simply by changing their current schema. They have not 'become' that schema; they can still only do the things you specified by granting select privileges on objects. They can't see anything else, and can't do any more to the objects they can see. They haven't inherited any of the privileges that schema has - so they can't create or drop objects under that schema, for instance. (You would have to explicitly grant them additional any privileges, which presumably you have no intention of doing.)
What they can do is reference those objects without having to prefix them with the schema name, and without having to create synonyms. But they can still only select from them (if that is the only privilege you granted).
When executing a PL/SQL block, any privileges granted to roles are ignored. Instead you must give specific users specific grants to run it. If I want to give DBAs access to a package or a function or a procedure, I can't give the DBA role a grant. I have to give a grant to each user in the DBA role, I have to remove the user's grant if they cease to be a DBA, and I have to add the grant to any new DBA.
I find this very hard to maintain.
My question is why does PL/SQL work this way? What design considerations did Oracle make to decide that this is how Roles and PL/SQL should work together? I've been unable to find an answer that isn't "that's just the way it is".
I think you may be fighting over Invokers rights vs Definers rights.
From Oracle docs:
During a server call, when a DR unit is pushed onto the call stack,
the database stores the currently enabled roles and the current values
of CURRENT_USER and CURRENT_SCHEMA. It then changes both CURRENT_USER
and CURRENT_SCHEMA to the owner of the DR unit, and enables only the
role PUBLIC. (The stored and new roles and values are not necessarily
different.) When the DR unit is popped from the call stack, the
database restores the stored roles and values. In contrast, when an IR
unit is pushed onto, or popped from, the call stack, the values of
CURRENT_USER and CURRENT_SCHEMA, and the currently enabled roles do
not change
So if you want Oracle to "respect the privileges granted by roles", then perhaps you want to use Invokers rights ( AUTHID CURRENT_USER clause)
It's probably a combination of laziness and the SET ROLE command.
I disagree that it's not allowed because of complex dependencies. Oracle already manages complex dependencies. And in 12c it is possible to grant a role to an object.
I think the real reason why objects don't inherit the roles of the user is because of the SET ROLE command. It's possible for a user to be assigned a role but to turn it on and off within a session. That's a silly feature and I've never seen it used. But theoretically it would require recompiling within the same session or transaction, which would be really confusing.
Otherwise if you drop a role then the PL/SQL package would become INVALID in some cases (without having the option to re-compile).
DROP ROLE ... is a DCL (Data Control Language) statement. Looks like Oracle decided: "A PL/SQL package shall not become INVALID by a DCL statement"
Maybe I am not understanding something correctly here, because I have done what you say can't be done. In fact, the Oracle documentation says it can be done. Look at the section on Procedure Security in this document. (#ibre5041)Nothing would have to be recompiled because the procedures run under the owner's privileges. The user's (or his roles') privileges are only checked for whether they are allowed to run the procedure.
What am I missing?
I'm think it is some historical heritage. When changing ROLE's object privs Oracle would have re-compile a lot of PL/SQL stored code. PS: you can also create something called "SCHEMA".
See CREATE SCHEMA statement.
For our application we're using outsorced Oracle administration. Now we'd like to prevent external oracle administrator from changing our data (DELETE, INSERT, UPDATE).
Is there any way how to do it?
Is there possible to REVOKE eg. UPDATE ANY TABLE to SYS account and is this sufficient?
I have read the Oracle Security Guide but haven't found anything. Only a statement: Do not use a DBA role which contains eg. the UPDATE ANY TABLE privilege.
I see I also should REVOKE GRANT ANY PRIVILEGE ...
Simply I'd need a complex guide how to do it and I'm not able to find any document about it.
Thanks
As security tightening exercise, I'm removing all system privileges from an oracle database user. Now this user ONLY has the following system privileges:
CREATE SESSION
UNLIMITED TABLESPACE
I was hoping that the user wont be able to do any DDL commands. But to my surprise, user can DROP TABLE in its own schema even though it can't create one.
Oracle documentation says prerequisite for DROP TABLE is "The table must be in your own schema or you must have the DROP ANY TABLE system privilege". Just that!!! I don't understand the security logic of Oracle but is there any way I can prevent Users from dropping their own tables?
The alternative would be creating another user to run the application and grant object access, which I'd rather like to avoid as there are potential issues.
A user will always have permissions to drop objects that they own. You can't prevent that by revoking privileges.
Since you're looking at tightening security, creating a new user and granting that user whatever privileges they need to manipulate the data is the right answer. The only people that ought to be logging in to a production database as a user that owns application objects are DBAs and then only when they are in the process of deploying changes to the schema. Everyone else should be logging in to the database as users other than the schema owner.
That being said, if the right solution is more work than you're prepared to undertake right now, a potential stopgap would be to create a DDL trigger on the database that throws an exception if a DROP is issued against an object in the specified schema. This is less secure than the proper solution. You may miss something when implementing the trigger, you or someone else may drop or disable the trigger and forget to re-enable it, etc. And it makes security reporting much more difficult because you've got a custom solution that isn't going to be obvious in the various security related data dictionary views which may create problems for auditors.
I have to install an application server that requires an user to write to the database, possibly create new schemes and such. However, I've always used the "work around" to assign the DBA Role to that user.
I have some questions, as I am not that deep into Oracle security.
Has the DBA role a level of privileges that can affect the whole Oracle installation?
Where can I find what privileges the DBA role exactly have?
How do I create an alternative role?
Thanks,
1) Yes, the dba role should have enough privileges to screw up a database beyond fixing.
2)
select *
from role_sys_privs
where grantee = 'DBA';
3) Unless you plan on having several user with similar privileges, I recommend creating a user and grant all needed privileges explicitly to this user instead of via a role.
You can read more about the topic in
Oracle Database Security Guide chapter 11, Administering User Privileges, Roles, and Profiles
First look into Ronnis' solution. If this is not sufficient create a package, owned by SYSTEM, and grant EXECUTE to the user or users that need it. Add procedures that perform the needed operations taking care to limit their power as much as possible.