# Install <tt>sepostgresql</tt> using <tt>yum</tt>. It assumes that <tt>postgresql</tt> or <tt>sepostgresql</tt> are not installed.

+

* Install <tt>sepostgresql</tt> using <tt>yum</tt>. It assumes that <tt>postgresql</tt> or <tt>sepostgresql</tt> are not installed.

-

# Initialise a database cluster so that <tt>sepostgresql</tt> can be started.

+

* Initialise a database cluster so that <tt>sepostgresql</tt> can be started.

-

# Create a database called <tt>testdb</tt>.

+

* Create a database called <tt>testdb</tt>.

-

# Using the PostgreSQL terminal client <tt>psql</tt> create a simple table with two columns and insert 4 rows (or tuples) of data demonstrating how to add and show the security context information associated with these objects. To enable the security context information to be distinguished between the various objects the following will be used:

+

* Using the PostgreSQL terminal client <tt>psql</tt> create a simple table with two columns and insert 4 rows (or tuples) of data demonstrating how to add and show the security context information associated with these objects. To enable the security context information to be distinguished between the various objects the following will be used:

{| border="1"

{| border="1"

Line 489:

Line 489:

|}

|}

-

# Finally run some <tt>sepostgresql</tt> specific functions and explain their results.

+

* Finally run some <tt>sepostgresql</tt> specific functions and explain their results.

SELinux PostgreSQL Support

This section gives an overview of the SE-PostgreSQL (version 8.4) extensions to support SELinux in F-12 and how the database context information is managed. It assumes some basic knowledge of PostrgreSQL that can be found at the following web site:

SE-PostgreSQL Overview

SE-PostgreSQL adds SELinux mandatory access controls (MAC) to database objects such as databases, tables, columns, rows (tuples), procedures and blobs (binary large objects)[1]. Figure 1 shows a simple database with one table, two columns and three rows, each with their object class and associated security context. The database object classes and permissions are described in the Object Classes and Permissions section.

database (db_database)

security_context = 'unconfined_u:object_r:sepgsql_db_t:s0:c999'

table (db_table)

security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c10'

column 1 (db_column)

security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c20'

column 2 (db_column)

security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c30'

row 1 (db_tuple)

security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c100'

1:1 Information

1:2 Information

row 2 (db_tuple)

security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c200'

2:1 Information

2:2 Information

row 3 (db_tuple)

security_context = 'unconfined_u:object_r:sepgsql_table_t:s0:c300'

3:1 Information

3:2 Information

Figure 1: Database Security Context Information - Showing the security contexts that can be associated to a database, table, columns and rows. It is also possible to associate security contexts to procedures and blobs.

SE-PostgreSQL Database Example has a walk-through on how to install SE-PostgreSQL on F-12 with setting up a database, adding tables etc. to show how the security context is used to enforce access control.

To use SE-PostgreSQL each GNU / Linux user must have a valid PostgreSQL database role (not to be confused with an SELinux role). The default installation shown in the SE-PostgreSQL Database Example section automatically adds a user called sepgsql with a suitable database role.

Using the SE-PostgreSQL Services diagram, the database client application (that could be provided by an API for Perl/PHP or some other programming language) connects to a database and executes SQL commands. As the SQL commands are processed by PostgreSQL, each operation performed on an object managed by the object manager (OM) is checked to see if this is allowed by the security policy or not. If the internal AVC does not hold the cached decision then the SELinux kernel Security Server is asked to resolve the query, with the result being cached internally by the OM.

Because PostgreSQL (and therefore SE-PostgreSQL) handles processes, files and directories as part of database operations, the OM also handles permissions for these objects where needed (see the sepostgresql-8.4.2-2583.fc12.src rpm - perms.c source code) by re-mapping these permissions internally.

SE-PostgreSQL supports SELinux services via the libselinux library, however it does not use the libselinux AVC API functions as it provides its own services. The AVC audits are logged into the sepostgresql.log file as described in the [#3.20.2.6.Logging Security Events|outline Logging Security Events] section.

The SE-PostgreSQL extensions to support MAC access control are described in the SE-PostgreSQL Extensions section below.

SE-PostgreSQL Extensions

The following sections describe the areas that have been extended to manage the security context information and enforce access control. There are a number of examples shown in the SE-PostgreSQL Database Example section that contains a walk-through of the installation, set-up and using SE-PostgreSQL to build a simple database with a single table, two columns and then adding a number of rows.

The main areas expanded are:

Adding an object manager that utilises SELinux support for policy enforcement via libselinux as shown in the SE-PostgreSQL Services diagram. This runs as the sepostgresql server (replacing the postgresql server).

The PostgreSQL internal tables (the system catalog) have also been enhanced to support security context information and are described in the [#3.20.1.5.Internal Tables|outline Internal Tables] section.

Returns the secid column entry from the pg_security table for the requested security context.

Additional Utilities

The pg_dump and pg_dumpall backup and restore utilities have been made SELinux-aware so that the security context is maintained.

An additional utility called sepg_ctl is also supplied that can be used to start, stop, restart, reload configuration files and report the status of a postgresql or sepostgresql server. sepg_ctl --help will list all the options.

Additional postgresql.conf Entries

The postgresql.conf file has the following additional entries added to manage the sepostgresql process[2]:

sepostgresql

SE-PostgreSQL activation option on or off. The default is on.

sepostgresql_mcstrans

If on (the default) SE-PostgreSQL uses mcstrans to translate the raw security context to a readable text field. If off the context is not translated.

sepostgresql_row_level

If on (the default), then row-level access controls (the db_tuple object class) will be enforced. If off row-level access control is not enforced.

Internal Tables

To support the overall database operation PostgreSQL has internal tables in the system catalog that hold information relating to user databases, tables etc. This section will only highlight the internal tables and their columns used by SE-PostgreSQL to support the object classes and security context entries using examples taken from the SE-PostgreSQL Database Example section.

Table 1 describes each of the tables used by SE-PostgreSQL to support security context relationships with example SELECT statements to retrieve the relevant information. The only internal table to actually hold security context strings is the pg_security table as all others reference these strings using identifiers as described in Table 2.

The pg_security table holds the security context strings and pointers for all objects including the rows (or tuples) as described in Table 2.

Table 1: PostgreSQL Internal Tables - Note that each table has other columns containing information, however only that relevant to the overview are described.

Table 2 describes each of the columns defined in the pg_security table with example entries after the table.

pg_security Column

Comment

secid

The unique identifier for this security context. The context is unique for this database (the datid column) and related OID (the relid column for the table, procedure, row etc.).

datid

The OID of the database to which this entry refers. This can be obtained from the pg_stat_database table as shown in the following example (that will list all contexts used by this instance of the database):

# datid '16384' is assigned by the system as the identifier for testdb database.
# relid '1249' is the pg_attribute (column) OID
# Therefore this entry is for a column in a table in the testdb database.
secid | datid | relid | seckind | secattr
------+-------+-------+---------+--------------------------------------------
16386 | 16384 | 1249 | l | unconfined_u:object_r:sepgsql_table_t:s0

# datid '16384' is assigned by the system as the identifier for testdb database.
# relid '16389' is a system pointer back to the table (pg_class.relfilenode) and
# column (pg_attribute.attrelid) in testdb database for a row of data.
# Therefore this entry represents the context for a row (tuple) of data in a
# table of the testdb database.
secid | datid | relid | seckind | secattr
-------+-------+-------+---------+--------------------------------------------
16393 | 16384 | 16389 | l | unconfined_u:object_r:sepgsql_table_t:s0:c110

Logging Security Events

SE-PostgreSQL manages its own AVC audit entries in the /var/log/sepostgresql.log file and by default only errors are logged (i.e. it does not add AVC entries into the standard audit.log). To be able to see greater detail then the boolean sepgsql_enable_audit_allow can be enabled (although this does show much gory detail). A pre-requisite is that the sepostgresql-devel policy module is installed. If the SE-PostgreSQL package has been installed as shown in the SE-PostgreSQL Database Example section, then the policy module would have been installed but not activated. To activate the module:

semodule -i /usr/share/selinux/packages/sepostgresql-devel.pp

Once installed, the boolean can be enabled by:

setsebool -P sepgsql_enable_audit_allow on

The following examples show an sepostgresql.log sequence when the sepgsql_enable_audit_allow boolean has been enabled and a user connects to a database and then performs a SELECT statement.

SE-PostgreSQL Database Example

Introduction

This section gives a run through installing and running a very simple database to show some of the SE-PostgreSQL features. The "Security-Enhanced PostgreSQL Security Wiki" contains a more complete coverage of the principles, however it does not have a simple walk-through.

The areas covered are:

Install sepostgresql using yum. It assumes that postgresql or sepostgresql are not installed.

Initialise a database cluster so that sepostgresql can be started.

Create a database called testdb.

Using the PostgreSQL terminal client psql create a simple table with two columns and insert 4 rows (or tuples) of data demonstrating how to add and show the security context information associated with these objects. To enable the security context information to be distinguished between the various objects the following will be used:

Name

Object

Context used

Database (testdb)

db_database

unconfined_u:object_r:sepgsql_db_t:s0

Table (info)

db_table

unconfined_u:object_r:sepgsql_table_t:s0:c10

Column 1 (user_name)

db_column

unconfined_u:object_r:sepgsql_table_t:s0:c20

Column 2 (email_addr)

db_column

unconfined_u:object_r:sepgsql_table_t:s0:c30

Row 1

db_tuple

unconfined_u:object_r:sepgsql_table_t:s0:c100

Row 2

db_tuple

unconfined_u:object_r:sepgsql_table_t:s0:c110

Row 3

db_tuple

unconfined_u:object_r:sepgsql_table_t:s0:c120

Row 4

db_tuple

unconfined_u:object_r::unconfined_t:s0:c130

Finally run some sepostgresql specific functions and explain their results.

The following assumptions have been made:

The user has a basic knowledge of databases and the SQL language.

SE-PostgreSQL or PostgreSQL are not installed.

The system used is Fedora 12 with the targeted policy (selinux-policy-targeted-3.6.32-103.fc12.noarch). This would have installed the postgresql policy modules by default.

Generally when adding entries to a database SE-PostgreSQL will use a default security context, however in this walk-through all entries will have specific security context defined for them (except the database (testdb) that will use the SE-PostgreSQL default).

SE-PostgreSQL Walk-through

Install sepostgresql using yum. This will install all the required components including postgresql:

This demo will create the test database and tables etc. as the sepgsql user:

su - sepgsql

Optionally, once logged on as the sepgsql user, the PostgreSQL createuser command can be used to allow other GNU / Linux users to access PostgreSQL by:

createuser [login_name]
# for example:
createuser root
Shall the new role be a superuser? (y/n) y
# This would allow root to use the PostgreSQL commands to manage
# the database as a superuser.

Now the testdb database itself needs to be created by the PostgreSQL createdb command:

createdb testdb

Once created, the PostgreSQL interactive terminal (psql) needs to be loaded so that SQL statements can be run against the database:

# This command will load psql and connect it to the testdb database:
psql testdb

Now that psql is active and connected to the testdb database SQL statements can be run. The first one is to display the security context of the database that requires some knowledge of how SE-PostgreSQL holds its internal parameters. As explained in the SELinux PostgreSQL Support section the main internal tables of interest are pg_database, pg_class, pg_attribute and pg_security, with pg_database holding the database name. Therefore if the following SQL statement is executed, the security context of the testdb database will be returned:

To demonstrate that SE-PostgreSQL will not allow entries to be entered unless the security context is valid, an entry will be made with a type of unconfined_t as this is not valid for the standard targeted policy. It is assumed that SELinux is in enforcing mode:

Reclaiming Unused Labels

When security contexts (labels) are no longer used, they are left in the pg_security table until they are reused or the space reclaimed. The following example runs the security_reclaim_label function that first returns 0, a row is then deleted (remember each row in the example database has a unique label) and the unused label space is then reclaimed.

↑ For the default installation described in the SE-PostgreSQL Database Example section, the configuration file is located at /var/lib/sepgsql/data/postgresql.conf.

↑ Note that the database context (OID = 1262 in the relid column) is listed as being under the datid of database '0'. The best way to retrieve the actual database context is by: SELECT security_context FROM pg_database WHERE datname = '...';