Introduction to CUBRID Security - Part II http://www.cubrid.org/?mid=intro_cubrid_security_2 Introduction to CUBRID Security - Part II en Tue, 07 Dec 2010 12:00:00 -0800 Mon, 23 Jan 2012 07:03:42 -0800 XpressEngine 1.4.4.1 Introduction to ... CUBRID http://www.cubrid.org/intro_cubrid_security_2 http://www.cubrid.org/intro_cubrid_security_2 Introduction to CUBRID Security - Part II
⇐Introduction to CUBRID Security - Part IDownload this document in PDF

Table of Contents

Welcome to the 2nd part of the CUBRID Security tutorial. In the Intro to CUBRID Security Part I we focused on:

  • The CUBRID database security model
  • Managing authorizations using SQL statements

In the 2nd part of the tutorial we will talk about CUBRID database metadata related to security, security related functions and guidelines for managing security.

In CUBRID, we have specialized system objects (catalogs) that hold information related to database security definitions:

  • System tables
    • _db_auth
    • _db_authorization
    • _db_authorizations
    • db_user
  • System views
    • o db_auth

If you need to find detailed information about the structure of each of these objects, use CUBRID Manager and look at the definitions and browse the data. You will also notice that in many other database metadata objects, there is a column usually named "owner", of type "db_user", which holds the owner of the data referenced. We will take a look now at two of these objects, which are probably the most used: db_auth and db_user.

db_auth

This view shows user authorization information for the database objects. Below is the table structure:

Attribute Name Description
grantor_name Authorization grantor
grantee_name Authorization grantee
class_name Class (table) object to which authorization is granted.
auth_type Type name of the authorization granted.
is_grantable YES if authorization for the class can be granted to other users and NO otherwise.

CUBRID db_auth Table

db_user

This view shows the users defined in the database, along with the groups and the authorizations. Below is the table structure:

Attribute Name Description
name User name
id User identifier
password User password. Not displayed to the user.
direct_groups Groups to which the user belongs directly
groups Groups to which the user belongs directly or indirectly
authorization Information of the authorization owned by the user
triggers Triggers that occur due to user actions

CUBRID db_user Table

Metadata Authorization

Metadata objects (=Catalog classes) are created to be owned by dba. However, dba can only execute SELECT operations. If dba executes operations such as UPDATE/DELETE, an authorization failure error occurs.

General users cannot execute queries on system catalog classes.

Although catalog virtual classes are created to be owned by dba, all users can perform the SELECT statement on metadata views (catalog virtual classes).

Of course, UPDATE/DELETE operations on catalog virtual classes are not allowed. Updating catalog classes/virtual classes is automatically performed by the system when users execute a DDL statement that creates/modifies/deletes a class/attribute/index/user/authorization.

SQL Functions

CURRENT_USER, USER, USER(), SYSTEM_USER()

CURRENT_USER and USER are used interchangeably. They return the user name that is currently logged in to the database as a string. USER() and SYSTEM_USER() are used interchangeably. They return the user name with a host name. Below you can see the examples:

--selecting the current user on the session SELECT USER; === <Result of SELECT Command in Line 1> === CURRENT_USER ====================== 'PUBLIC' SELECT USER(), CURRENT_USER; === <Result of SELECT Command in Line 1> === user() CURRENT_USER ============================================ 'PUBLIC@cdbs006.cub' 'PUBLIC'

db_user & db_authorizations methods

The database administrator (dba) can check and modify user authorization by calling authorization-related methods defined in db_user (where information about database user is stored), and db_authorizations (the system authorization metadata table). The administrator can specify db_user or db_authorization depending on the method to be called (and save the return value of a method to a variable).

Note: Some of these methods can be called only by dba or members of dba group.

login(…)

As a class method of db_user class, this method is used to change the users who are currently connected to the database. The name and password of a new user to connect are given as parameters, and they must be string type. If there is no password, a blank string ('') can be used as the parameter. dba and dba members can call the login(…) method without a password.

-- Connect as dba user who has no password CALL login ('dba', '') ON CLASS db_user; -- Connect as a user_1 whose password is cubrid CALL login ('user_1', 'cubrid') ON CLASS db_user;

add_user(...)

As a class method of db_user class, this method is used to add a new user. The name and password of a new user to add are given as parameters, and they must be string type. At this time, the new user name should not duplicate any user name already registered in a database. The add_user(…) can be called only by dba or members of dba group.

-- Add user_2 who has no password CALL add_user ('user_2', '') ON CLASS db_user; -- Add user_3 who has no password, and save the return value of a method into an admin variable CALL add_user ('user_2', '') ON CLASS db_user to admin;

drop_user(…)

As a class method of db_user class, this method is used to drop an existing user. Only the user name to be dropped is given as a parameter, and it must be a string type. However, the owner of a class cannot be dropped thus dba needs to specify a new owner of the class before dropping the user. The drop_user(…) method can be also called only by dba or members of dba.

-- Delete user_2 CALL drop_user ('user_2') ON CLASS db_user;

find_user(…)

As a class method of db_user class, this method is used to find a user who is given as a parameter. The name of a user to be found is given as a parameter, and the return value of the method is stored into a variable that follows 'to'. The stored value can be used in a next query execution.

-- Find user_2 and save it into a variable called 'admin' CALL find_user ('user_2') ON CLASS db_user to admin;

set_password(…)

This method is an instance method that can call each user instance, and it is used to change a user's password. The new password of a specified user is given as a parameter. General users other than dba and dba group members can only change their own passwords.

-- Add user_4 and save it into a variable called user_common CALL add_user ('user_4','') ON CLASS db_user to user_common; -- Change the password of user_4 to 'abcdef' CALL set_password('abcdef') on user_common;

change_owner(…)

As a class method of db_authorizations class, this method is used to change the owner of a class. The name of a class for which you want to change the owner, and the name of a new owner are given as parameters. At this time, the class and owner that are specified as a parameter must exist in a database. Otherwise, an error occurs. change_owner(…) can be called only by dba or members of dba group.

-- Change the owner of table_1 to user_4 CALL change_owner ('table_1', 'user_4') ON CLASS db_authorizations;

SQL Auditing

Note: You will talk in this section only about SQL logs. Other CUBRID logs, like error or access log are not in the scope of this tutorial.

By default, the execution of the SQLs is logged by the CUBRID broker, in the following folder (relative to the installation path): logbrokersql_log

CUBRID SQL Log

Warning: All the executed queries are stored in the log file only if the SQL_LOG parameter of the Broker is ON.

If you open one of the log files in this location, you will find in there all the details regarding the SQLs executed in the database:

CUBRID SQL Log File

CUBRID Manager provides a useful utility - Execute log, which can be used to re-execute the SQL log stored in the log script. You can tune queries and correct errors by modifying and re-executing log queries.

Other things to know about:

  • You can view the execution log of the trigger from a terminal by using the SET TRIGGER TRACE statement.
  • There are three types of logs that relate to starting the Broker: access, error and SQL logs. Each log can be found in the log directory under the installation directory. You can change the directory where these logs are to be saved through LOG_DIR and ERROR_LOG_DIR parameters of the broker environment configuration file (cubrid_broker.conf).
  • The size of the SQL log file to be generated cannot exceed the value set for the SQL_LOG_MAX_SIZE parameter.
  • CUBRID provides the broker_log_top, broker_log_converter, and broker_log_runner utilities to manage SQL logs.
  • More information regarding logging in CUBRID can be found here: http://www.cubrid.org/manual/840/en/CUBRID%20Manager%20Server%20Logs.

CUBRID Specifics

  • You can't specify from where (IP address) a user can login to the server; if you need to implement such a functionality, consider using a firewall (see http://www.cubrid.org/general_security_configuration)
  • There is currently no support for restricting the time of the day/the periods when the user can connect to the CUBRID database. Please use a firewall to enforce such restrictions.
  • The cubrid createdb utility creates databases and initializes them with the built-in CUBRID system tables. But it can also be used to define initial users to be authorized in the - see http://www.cubrid.org/manual/840/en/Database%20Administration-Creating%20Database.
  • When a slave database is created, the ownership of every class is changed to that of the replication user.
  • The public user can't be removed from a database.
  • You must always run the distribution database with the dba account to ensure security. The repl_make_distdb utility requires the name of the distribution database and the password for its dba account.

Security Guidelines

  • Make sure the password for the dba user is "strong" enough; you can find some guidelines on how to create strong passwords here: http://en.wikipedia.org/wiki/Password_strength.
  • When you connect to the database using the CUBRID Manager, the initial user ID and password are admin/admin. Use them only for the first connection, but you must change the password immediately after for obvious security reasons.
  • Do not use the dba user to test your application or to setup the database structure.
  • Do not store users and password related data in applications' files.
  • Make sure you enforce a policy of changing the passwords periodically; CUBRID does not have a way to automatically "expire" passwords validity - it is up to the CUBRID administrator to setup and enforce such a best practice.
  • Do not give anyone access to the db_user table.
  • Give permissions only as needed and use different logins for different applications.

See also

This concludes the 2nd part of the CUBRID Security tutorial. Please let us know your feedback and remember to periodically check the CUBRID web site for other tutorials and resources.

]]> Wed, 08 Dec 2010 02:53:04 -0800