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.
Related
I have a database and want to give out roles and privileges.
My aim is to allow multiple users - all have the same privileges - to be able to create, edit and view the tables (That's it).
I understand there are user table privileges that allow a user to Create, alter, drop and delete items in tables. But I also understand that there is a
resource user pre-defined role that allows a user to do the same thing.
Would I offer both of the roles? The table-level privileges and predefined roles? What would happen if I do offer both? Can I?
That is more a database administration question, as you have users that develop their own tables. And the heart of your question, "one size fits all prepacked" role RESOURCE or better a bespoke solution for your set of users is really one of administrative style, taste, and your special case.
Personally, I don't like the role RESOURCE as it lacks the privilege CREATE VIEW.
Please note that the privilege CREATE TABLE (granted directly or via a role) allows the user to create tables in his/her own schema. To create tables in other schemas (or "all the tables on the database"), you need the privilege CREATE ANY TABLE. See documentation for details.
Taking a course on Oracle database security, I have learned profiles are being created to restrict access of some users to some resources.On the other hand, we have functions and policies, which can restrict users too, but I cannot clear the difference between these two. Why we use profiles while we can create policies for users?
A Profile restricts how much system resource a user is allowed: how many concurrent sessions they can have, how much CPU they can use, etc. We can also use Profiles for password management: how many failed logins they're allowed, how long a password lasts, etc.
So a Profile defines the broad bounds of system usage. It governs hardware and database access.
By "policy" I assume you mean Fine-Grained Access Control. These policies set limits to what a user can see of an individual table: what rows they can see and what columns. So we could.use FGAC policy to allow a manager to see all the details for their direct reports but only certain information for all other employees.
So a Policy applies further restrictions to a table which a user already has access to. Which highlights the missing P from your question.
A Privilege grants a user permission to do a specific thing. By default a user cannot do anything in a database. They can't even connect to it without the CREATE SESSION privilege. There are two levels of Privilege. A System Privilege allows a user to do general activities like create a table, execute any procedure, query the data dictionary, etc. A Table Privilege allows a user to do something with a specific object owned by a different user, such as select from my.employee_table, execute her.string_function, etc.
So you can see how Privileges and FGAC Policies interact. I might grant you select and update on my.employee_table but enforce a policy that only allows you to update records for department 40.
To summarise. There are four levels of user restrictions.
In descending order of breadth:
Profile
System Privilege
Table (i.e. Object) Privilege
FGAC Policy
Note: 12c introduced some called an Audit Policy. Clearly that is relevant to the general topic of Oracle database security but I don't think it's pertinent here.
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
I just learned that by default, Oracle does not grant the 'create session' privilege to new users. No problem, I can do that myself.
Anyway, I'm curious: why would I want an Oracle user without 'create session' privilege? What can it be used for? There must be some non-obvious use. My first thought was running database jobs, but AFAIK they need this privilege, as well...
It could be used for a schema with some shared objects, rather than a real user.
Other users (who can create a session) would be accessing the tables and procedures owned by that user.
But according to Tom, it was just a way to lock an account, before accounts could be locked.