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.
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).
I have a usecase where I need to block access to all objects in a schema temporarily while I perform some massive changes. I plan to perform the changes as the schema owner. Once I am done I want to enable access back. I am currently exploring two options and would like to know your thoughts as to which one works better :
Lock all accounts that go against the database objects in target schema.
Revoke grants on the database objects and hence preventing external users from using it.
Is there are better way? I want the process to be as smooth as possible and insure that no one is able to get to the target schema while the change is going on
Trigger. This trigger works for everybody except the user with dba role.
CREATE OR REPLACE TRIGGER logon_audit_trigger
AFTER LOGON
ON DATABASE
DECLARE
BEGIN
raise_application_error (-20001, 'You cannot login.');
END;
If you want to know who and where is trying to login. You can get thses information from SYS_CONTEXT.
SELECT SYS_CONTEXT ('USERENV', 'SESSION_USER')
FROM DUAL;
You could consider to quiesce the database. The downsides to locking out users or revoking permissions is that users will receive errors (you don't have access or you can't login, etc...). Quiesceing the database means that active sessions will finish their work, but then will hang until the database is un-quiesced. Then, you perform your modifications and will be guaranteed that nothing can block your exclusive access to the objects you are updating. After your update (or even during your update after you have the lock on the object in question), unquiesce the database.
Of course, the downside to this approach is that this is across the entire database instead of to just one schema. The advantage to this is that your users won't experience any error messages, and if you turn your DML into DDL (as described below) to greatly speed up the downtime window, the majority of your users shouldn't experience much more than a few seconds of inactivity.
There is a good write up on quiesceing the database at Oracle FAQ. You would have to get your DBA's involved to both quiesce the database and to put your changes live as only system or sys can perform this operation.
For DML, you could consider creating a new table with the data that you want before the downtime window starts. Then when the downtime window starts, rename the old table, rename the new table as the old table, recreate the permissions, for a much faster downtime window (since this effectively turns a DML update into DDL). Tom Kyte has a discussion of this approach here.
Also, it goes without saying that proper testing in a testing environment of the above procedures should be done, which will iron out any gotchas in this process and give you a pretty good idea of how long the system will need to be quiesced for.
I'm using Oracle's 10g version.
In the database, I would like to create a configuration table and fill it with data.
Then the other users can not change anything in it, and even better that it was not at all visible to other users. Is it possible to somehow hide the table?
Regards
Create a separate schema for that table. Create a package that provides an API to your configuration data (e.g. to get a value that is needed by another program).
Revoke CREATE SESSION privilege from that schema (i.e. just don't grant any privileges to the schema at all). Don't grant any privileges on the table. The only users who will be able to see the table are those with DBA privileges.
The only thing that database sessions will be able to do is execute the package, IF they have been granted EXECUTE privilege on it.
If you do not grant enough privileges to other users, they could not see your objects.
I want to create the user and the database within that user. But when I tried to create database its giving the warning message as
ERROR at line 1:
ORA-01501: CREATE DATABASE failed
ORA-01100: database already mounted
Then I tried
STARTUP NOMOUNT;
Its giving the warning message for insufficient privileges even I have given all the permission to that particular user.
Can any one please help in finding the solution for this?
You don't create a database under a user in Oracle; I believe you're using terminology from another database poduct. The equivalent is a schema, which is a logical container for a group of objects. User and schema are essenentially synonymous in Oracle - when you create a user is automatically has its own schema.
You create the database once (which you already seem to have done, or had done for you), then create as many schemas/users as your application needs. You don't ever rerun the create database under normal circumstances - you certainly wouldn't as a normal user.
If you connect as that user you will be able to create tables, views, packages etc., assuming it has really been granted all the necessary privileges.
Why does a user needs privileges over his own schema to create packages and triggers?
Are you asking why users need particular priviliges (i.e. CREATE TABLE, CREATE PROCEDURE, etc) in order to create particular types of objects in their own schema?
If so, the natural answer would be that good security begins with the principle of least privilege-- that is, a user should only have those privileges that they truly need to do their job and no more. DBAs frequently want to create read-only accounts for users in the production database (business analysts, for example, often need to do different sorts of ad hoc reporting, developers may need access to troubleshoot certain types of problems, etc). If a user were always able to create objects in their own schema, those read-only users would suddenly be able to deploy code to the production database without going through change control or even necessarily testing anything. And that generally leads to a proliferation in code doing basically the same thing (i.e. a dozen analysts each have a procedure to calculate sales tax in their own schemas) but each of which has its own unique signature, logic, requirements, assumptions, etc. And heaven forbid that one of those analysts get fired because the DBA would naturally delete their account, only to find out that some crucial report depended on code that existed only in that analyst's schema.
I can't give you the "official" answer, but I can take a stab at the reasoning behind how it works. On the project I work on, Oracle Developers are the ones that deploy the triggers and packages into the database schema. But we have other teams of Java developers and testers, etc. Once the schema are migrated into the Test and then Production environments, we don't want the testers or the end user applications to be able to arbitrarily modify the triggers and packages associated with that schema, as that could invalidate the integrity of any testing they are doing (or cause even worse issues on the production system).
So within the test/production environments, you want the testers, the Java developers, and the end-user application to be able to read and write data to the schema, but not modify the triggers and packages which encompass the baselined code.
Why does a user needs privileges over
his own schema to create packages and
triggers
They do not.
Their own schema implies the ownership (or namespace) defined by username.object
All a user needs to create a trigger in their own schema is:
a table in their own schema
the create trigger privilege
All a user needs to create a package in their own schema is:
the create package privilege
If the user wants to create objects in another schema or that references other objects, or that requires storage in a tablespace then they will need permissions on those foreign objects.