Dear Readers,
My name is Franz Devantier, creator of this blog. I am an Oracle Certified
Professional (OCP DBA 11g) Security DBA.
I will be sharing with you the basic duties of an Oracle DBA, and also
some of the undocumented, and not so well known tasks.
I will make a deal with you: If you refer me to a company that needs
database support, from a few hours per week to full time, and I am able to sign
a contract with them.
Then I will give you 10% of the monthly
contract or deal price every month. When
the contract ends, and we re-sign the contract, I will again give you 10% of
the monthly contract price. This will go
on until the company no longer employs or contracts me or my agents to look
after their databases.
I can do this, because that 10% is my
marketing budget. When we re-sign the
contract, in the future, it may depend on you giving the thumbs up again, and
that is worth 10% of the monthly contract price, to be given to you as
commission.
Contact:
Franz
Security
Policies - Part 11
Grant necessary privileges only.
Practice the Principle of least privilege.
Do not provide database users more privileges than are
necessary for them to complete their tasks.
The “Principle of least privilege”, is that users will be given only
those privileges that are actually required to efficiently perform their
jobs. In order to implement this
principle, you need to restrict as much as possible:
-> The number of SYSTEM and OBJECT privileges granted to
database users.
-> The number of people who are allowed to make
SYS-Privileged connections to the database.
For example there is typically no need to grant DROP ANY TABLE to a
non-DBA-privileged user.
Revoke
unnecessary privileges from the PUBLIC role.
Revoke all the unnecessary privileges and roles from the
PUBLIC role. PUBLIC acts as a default
role granted to every user in an Oracle database. If the privileges are granted to PUBLIC, then
any database user can execute those privileges.
For example EXECUTE privileges on PL/SQL packages would potentially
enable a user with almost no privileges to run some very powerful packages,
that he/she would not normally have had access to. Some of these packages can cause damage to
the installation, either accidentally or maliciously.
Below are some of the more powerful packages that could be
misused:
Package or Subtype
|
Description
|
DBMS_RANDOM
|
This package can be used to
encrypt stored data. Generally, most users should not have the privilege to
encrypt data since encrypted data may be non-recoverable if the keys are not
securely generated, stored, and managed.
Encryption can easily become a one way process.
|
HTTPURITYPE
|
This subprogram is a subtype
of the UriType that provides support for the HTTP protocol. It uses the
UTL_HTTP package underneath to access the HTTP URLs. Proxy and secure wallets
are not supported in this release. Downgrade grants on HTTPURITYPE to the
minimum needed in your environment, or revoke all grants if none of your
applications need it.
|
UTL_HTTP
|
This package allows the
database server to request and retrieve data using HTTP.
|
UTL_INADDR
|
This package allows arbitrary
domain name resolution to be performed from the database server. Granting
this package to the PUBLIC role may permit unauthorized domain name
resolution.
|
UTL_SMTP These packages and subtype
should be revoked from PUBLIC and made executable for an application only
when absolutely necessary.
|
This package permits
arbitrary mail messages to be sent from one arbitrary user to another
arbitrary user. Granting this package to the PUBLIC role may permit
unauthorized exchange of mail messages.
|
UTL_TCP
|
This package permits outgoing
network connections to be established by the database server to any receiving
(or waiting) network service. Granting this package to PUBLIC may permit
arbitrary data to be sent between the database server and any waiting network
service. This is a big security
issue. Revoke this from PUBLIC if
appropriate.
|
The packages mentioned above are very useful to the
applications that use them. However they
require proper configuration and usage for safe and secure operation. These packages may not be suitable for all
applications, because of the security implications.
If an application does need these packages or a subset of
them, the create a role with the EXECUTE privilege for the needed package, and
assign these roles only to applications that specifically need and use
them. Even better would be to grant
these privileges to secure application roles.
In future releases of Oracle, the intention is to revoke
such privileges from the PUBLIC role.
Grant a role to users only if they need all privileges of
the role.
Roles are very useful for quickly granting a group of
privileges to a user. The Oracle-defined
roles are more generic, and may contain more privileges than you want to
grant. So it is best to create your own
custom roles. You will need to design
and create roles that contain only those privileges that are required for a
specific group of users. Create a few
custom roles, so that you will have a role that fits as closely as possible to
a user’s needs, based on the job responsibility.
If the application uses don’t need all of the privileges in
a role or a set of roles, then you need to create another role or set of roles
that contain just the right privileges for the application users, with specific
job functions.
If you are not going to drop the user scott, or keep scott
permanently locked and expired, then you should drop the privileges that are
assigned to scott, like the CREATE DBLINK system privilege. Because you can’t drop individual privileges
that are acquired by means of a role, you will need to drop the entire
role. You can create a new role, with
just those minimal privileges needed for the user, and grant that role to the
user. It is good practice to drop the
CREATE DBLINK system privilege from all users who don’t specifically need it.
Restrict permissions on run-time facilities.
Do not assign all permissions to any database server
run-time utility. For example the Java
Virtual Machine (OJVM). Grant specific
permissions for such utilities, that may execute files and packages outside of
the database server; and then only to the explicit document root file paths.
Here is a run-time call that is vulnerable to malicious
action:
dbms_java.grant
permission(‘SCOTT”,’SYS:java.io.FilePermission’,’<<ALL
FILES>>’,’read’);
Here is a run-time call that is less vulnerable:
dbms_java.grant_permission(‘SCOTT’,’SYS:java.io.FilePermission’,’<<ROOT
DRECTORY PATH>>,’read’);
Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com
Classifieds
No comments:
Post a Comment