PostgreSQL 9.1beta2 Documentation
Prev | Fast Backward | Appendix F. Additional Supplied Modules | Fast Forward | Next

# F.38. sepgsql

`sepgsql` is a loadable module which supports label-based mandatory access control (MAC) based on SELinux security policy.

Warning
This implementation has signification limitations, and does not enforce mandatory access control for all actions. See Section F.38.6.

## F.38.1. Overview

This module integrates with SELinux to provide an additional layer of security checking above and beyond what is normally provided by PostgreSQL. From the perspective of SELinux, this module allows PostgreSQL to function as a user-space object manager. Each table or function access initiated by a DML query will be checked against the system security policy. This check is an additional to the usual permissions checking performed by PostgreSQL.

SELinux access control decisions are made using security labels, which are represented by strings such as `system_u:object_r:sepgsql_table_t:s0`. Each access control decision involves two labels: the label of the subject attempting to perform the action, and the label of the object on which the operation is to be performed. Since these labels can be applied to any sort of object, access control decisions for objects stored within the database can be (and, with this module, are) subjected to the same general criteria used for objects of any other type (e.g. files). This design is intended to allow a centralized security policy to protect information assets independent of the particulars of how those assets are stored.

The SECURITY LABEL statement allows assignment of a security label to a database object.

## F.38.2. Installation

This module can only be used on Linux 2.6.28 or higher with SELinux enabled. It is not available on any other platform, and must be explicitly enabled using `--with-selinux`. You will also need libselinux 2.0.93 or higher and selinux-policy 3.9.13 or higher (some distributions may backport the necessary rules into older policy versions).

The `sestatus` command allows you to check the status of SELinux.

    $ sestatus
    SELinux status:                 enabled
    SELinuxfs mount:                /selinux
    Current mode:                   enforcing
    Mode from config file:          enforcing
    Policy version:                 24
    Policy from config file:        targeted

If SELinux is disabled or not installed, you must set that product up first before installing this module.

To use this module, you must add include `sepgsql` in shared_preload_libraries. The module will not function if loaded in any other manner. Once the module is loaded, you should execute `sepgsql.sql` in each database. This will install functions needed for security label management, and assign initial security labels.

The following instructions that assume your installation is under the `/usr/local/pgsql` directory. Adjust the paths shown below as appropriate for your installation.

    $ initdb
    $ vi $PGDATA/postgresql.conf
    $ for DBNAME in template0 template1 postgres; do
      postgres --single -F -O -c exit_on_error=true $DBNAME \
          < /usr/local/pgsql/share/contrib/sepgsql.sql > /dev/null
      done

If the installation process completes without error, you can now start the server normally.

## F.38.3. Regression Tests

Due to the nature of SELinux, running the regression tests for this module requires several additional configuration steps.

First, build and install the policy package for the regression test. The `sepgsql-regtest.pp` is a special purpose policy package which provides a set of rules to be allowed during the regression tests. It should be built from the policy source file (`sepgsql-regtest.te`), which is normally done using `make`. You will need to locate the appropriate Makefile on your system; the path shown below is only an example. Once built, you can install this policy package using the `semodule` command, which links supplied policy packages and loads them into the kernel space. If this package is correctly installed, ``semodule` -l` should list sepgsql-regtest as an available policy package.

    $ make -C ./contrib/sepgsql -f /usr/share/selinux/devel/Makefile
    $ su
    # semodule -u ./contrib/sepgsql/sepgsql-regtest.pp
    # semodule -l
        :
    sepgsql-regtest 1.03
        :

Second, turn on `sepgsql_regression_test_mode`. We don't enable all the rules in the `sepgsql-regtest.pp` by default, for your system's safety. The `sepgsql_regression_test_mode` parameter is associated with rules to launch regression test. It can be turned on using `setsebool` command.

    $ su
    # setsebool sepgsql_regression_test_mode on
    # getsebool sepgsql_regression_test_mode
    sepgsql_regression_test_mode --> on

Last, kick the regression test from the `unconfined_t` domain.

The `id` command tells us the current working domain. Confirm your shell is now performing with the `unconfined_t` domain as follows.

    $ id -Z
    unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

See Section F.38.7 for details on adjusting your working domain, if necessary.

If `pg_regress` fails to launch the `psql` command, you may need to ensure that the `psql` command is labeled as `bin_t`. If it is not, the `restorecon` command can often be used to fix up security labels within the PostgreSQL installation directory.

    $ restorecon -R /usr/local/pgsql/

## F.38.4. GUC Parameters

`sepgsql.permissive` (`boolean`)

  This parameter enables SE-PostgreSQL to function in permissive mode, regardless of the system setting. The default is off. This parameter can only be set in the `postgresql.conf` file or on the server command line.

  When this parameter is on, SE-PostgreSQL functions in permissive mode, even if the platform system is working in enforcing mode. This parameter is primarily useful for testing purposes.

`sepgsql.debug_audit` (`boolean`)

  This parameter enables the printing of audit messages independent from the policy setting. The default is off (according to the security policy setting).

  The security policy of SELinux also has rules to control whether or not particular accesses are logged. By default, access violations are logged, but allowed accesses are not.

  This parameter forces all possible logging to be turned on, regardless of the system policy.

## F.38.5. Features

### F.38.5.1. Controlled Object Classes

The security model of SELinux describes all the access control rules as a relationship between a subject entity (typically, it is a client of database) and an object entity, each of which is identified by a security label. If access to an unlabelled object is attempted, the object is treated as if it were assigned the label `unlabeled_t`.

Currently, sepgsql allows security labels to be assigned to schemas, tables, columns, sequences, views, and functions. When sepgsql is in use, security labels are automatically assigned to supported database objects at creation time. This label is called as a default security label, being decided according to the system security policy, which takes as input the creator's label and the label assigned to the new object's parent object.

A new database object basically inherits the security label of the parent object, except when the security policy has special rules known as type-transition rules, in which case a different label may be applied. For schemas, the parent object is the current database; for columns, it is the corresponding table; for tables, sequences, views, and functions, it is the containing schema.

### F.38.5.2. DML Permissions

For tables, `db_table:select`, `db_table:insert`, `db_table:update` or `db_table:delete` is checked for all the referenced target tables depending on the sort of statement; in addition, `db_table:select` is also checked for all the tables that contain the columns referenced in the `WHERE` or `RETURNING` clause, as a data source of `UPDATE`, and so on.

    UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;

In this case, we must have `db_table:select` in addition to `db_table:update`, because `t1.a` is referenced within the `WHERE` clause. Column-level permissions will also be checked for each referenced column.

The client must be allowed to access all referenced tables and columns, even if they originated from views which were then expanded, so that we apply consistent access control rules independent of the manner in which the table contents are referenced.

For columns, `db_column:select` is checked on not only the columns being read using `SELECT`, but being referenced in other DML statements.

Of course, it also checks `db_column:update` or `db_column:insert` on the column being modified by `UPDATE` or `INSERT`.

    UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;

In this case, it checks `db_column:update` on the `t1.x` being updated, `db_column:{select update}` on the `t1.y` being updated and referenced, and `db_column:select` on the `t1.z` being only referenced in the `WHERE` clause. `db_table:{select update}` will also be checked at the table level.

For sequences, `db_sequence:get_value` is checked when we reference a sequence object using `SELECT`; however, note that we do not currently check permissions on execution of corresponding functions such as `lastval()`.

For views, `db_view:expand` shall be checked, then any other corresponding permissions shall be also checked on the objects being expanded from the view, individually.

For functions, `db_procedure:{execute}` is defined, but not checked in this version.

The default database privilege system allows database superusers to modify system catalogs using DML commands, and reference or modify toast tables. These operations are prohibited when sepgsql is enabled.

### F.38.5.3. DDL Permissions

On SECURITY LABEL command, `setattr` and `relabelfrom` shall be checked on the object being relabeled with an old security label, then `relabelto` on the supplied new security label.

In the case where multiple label providers are installed and the user tries to set a security label, but is not managed by SELinux, only `setattr` should be checked here. This is currently not checked due to implementation restrictions.

### F.38.5.4. Trusted Procedure

Trusted procedures are similar to security definer functions or set-uid commands. SELinux provides a feature to allow trusted code to run using a security label different from that of the client, generally for the purpose of providing highly controlled access to sensitive data (e.g. rows might be omitted, or the precision of stored values might be reduced). Whether or not a function acts as a trusted procedure is controlled by its security label and the operating system security policy. For example:

    postgres=# CREATE TABLE customer (
                   cid     int primary key,
                   cname   text,
                   credit  text
               );
    CREATE TABLE
    postgres=# SECURITY LABEL ON COLUMN customer.credit
                   IS 'system_u:object_r:sepgsql_secret_table_t:s0';
    SECURITY LABEL
    postgres=# CREATE FUNCTION show_credit(int) RETURNS text
                 AS 'SELECT regexp_replace(credit, ''-[0-9]+$'', ''-xxxx'', ''g'')
                            FROM customer WHERE cid = $1'
               LANGUAGE sql;
    CREATE FUNCTION
    postgres=# SECURITY LABEL ON FUNCTION show_credit(int)
                   IS 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0';
    SECURITY LABEL

The above operations should be performed by an administrative user.

    postgres=# SELECT * FROM customer;
    ERROR:  SELinux: security policy violation
    postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
     cid | cname  |     show_credit
    -----+--------+---------------------
       1 | taro   | 1111-2222-3333-xxxx
       2 | hanako | 5555-6666-7777-xxxx
    (2 rows)

In this case, a regular user cannot reference `customer.credit` directly, but a trusted procedure `show_credit` enables us to print the credit card number of customers with some of the digits masked out.

### F.38.5.5. Miscellaneous

We reject the LOAD command across the board, because any module loaded could easily circumvent security policy enforcement.

## F.38.6. Limitations

Userspace access vector cache

  sepgsql does not yet support an access vector cache. This would likely improve performance.

Data Definition Language (DDL) Permissions

  Due to implementation restrictions, DDL permissions are not checked.

Data Control Language (DCL) Permissions

  Due to implementation restrictions, DCL permissions are not checked.

Row-level access control

  PostgreSQL does not support row-level access; therefore, sepgsql does not support it either.

Covert channels

  sepgsql never tries to hide existence of a certain object, even if the user is not allowed to the reference. For example, we can infer the existence of an invisible object as a result of primary key conflicts, foreign key violations, and so on, even if we cannot reference contents of these objects. The existence of a top secret table cannot be hidden; we only hope to conceal its contents.

## F.38.7. External Resources

SE-PostgreSQL Introduction

  This wiki page provides a brief-overview, security design, architecture, administration and upcoming features.

Fedora SELinux User Guide

  This document provides a wide spectrum of knowledge to administer SELinux on your systems. It focuses primarily on Fedora, but is not limited to Fedora.

Fedora SELinux FAQ

  This document answers frequently asked questions about SELinux. It focuses primarily on Fedora, but is not limited to Fedora.

## F.38.8. Author

KaiGai Kohei `<kaigai@ak.jp.nec.com>`

Prev | Home | Next
seg | Up | spi