path: root/doc/src/sgml/sepgsql.sgml

<!-- doc/src/sgml/sepgsql.sgml -->

<sect1 id="sepgsql">
 <title>sepgsql</title>

 <indexterm zone="sepgsql">
  <primary>sepgsql</primary>
 </indexterm>

 <para>
  <filename>sepgsql</> is a loadable module which supports label-based
  mandatory access control (MAC) based on <productname>SELinux</> security
  policy.  This implementation is not complete, and primarily provides
  protection for Data Manipulation Language statements (DML).  Support for
  fine-grained access control of Data Definition Language (DDL) and Data
  Control Language (DCL) statements may be added in a future release.
 </para>
 <para>
  This extension won't build at all unless the installation was configured
  with <literal>--with-selinux</>.
 </para>

 <sect2 id="sepgsql-overview">
  <title>Overview</title>

  <para>
   This module integrates with <productname>SELinux</> to provide an
   additional layer of security checking above and beyond what is normaly
   provided by <productname>PostgreSQL</productname>.  From the perspective of
   <productname>SELinux</>, this module allows
   <productname>PostgreSQL</productname> 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
   <productname>PostgreSQL</productname>.
  </para>

  <para>
   <productname>SELinux</productname> access control decisions are made using
   security labels, which are represented by strings such as
   <literal>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.
  </para>

  <para>
   The <xref linkend="sql-security-label"> statement allows assignment of
   a security label to a database object.
  </para>

 </sect2>
 <sect2 id="sepgsql-installation">
  <title>Installation</title>

  <para>
   This module has several prerequisites.
  </para>

  <variablelist>
   <varlistentry>
    <term><productname>Linux kernel</productname></term>
    <listitem>
     <para>
      v2.6.28 or later with built with SELinux enabled
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term><productname>libselinux</productname></term>
    <listitem>
     <para>
      v2.0.80 or later
     </para>
     <para>
      This library provides a set of APIs to communicate with
      <productname>SELinux</> in kernel.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term><productname>selinux-policy</productname></term>
    <listitem>
     <para>
      v3.9.13 or later
     </para>
     <para>
      The default security policy provides a set of access control rules.
      Some distributions may backport necessary rules to older policy versions.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
  <para>

   <productname>sepgsql</> needs <productname>SELinux</> being
   available on the platform. You can check the current setting using
   <command>sestatus</>.
<screen>
$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
</screen>
   If <productname>SELinux</> is disabled or not installed, you must set
   that product up first before installing this module.
  </para>

  <para>
   At compile time, pass the <literal>--with-selinux</> option to
   the <command>configure</> script to enable this module.

<screen>
$ ./configure --enable-debug --enable-cassert --with-selinux
$ make
$ make install
</screen>
  </para>

  <para>
   Following <command>initdb</>, add <literal>'$libdir/sepgsql'</>
   to <xref linkend="guc-shared-preload-libraries"> in
   the <filename>postgresql.conf</>.  Note that <productname>sepgsql</>
   must be loaded at server startup.
  </para>

  <para>
   Next, load the <filename>sepgsql.sql</filename> script for each database.
   It installs functions for security label management, and attempts to assign
   initial labels to the target objects.
  </para>

  <para>
   The following instruction assumes your installation is under the
   <filename>/usr/local/pgsql</> directory, and the database cluster is in
   <filename>/usr/local/pgsql/data</>. Adjust the paths shown below as
   appropriate for your installaton.
  </para>

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

  <para>
   If the installation process completes without error, you can now start the
   server normally.
  </para>
 </sect2>

 <sect2 id="sepgsql-regression">
  <title>Regression Tests</title>
  <para>
   Due to the nature of <productname>SELinux</productname>, running the
   regression tests for this module requires several additional configuration
   steps.
  </para>

  <para>
   First, install the policy package for the regression test.
   The <filename>sepgsql-regtest.pp</> is a special purpose policy package
   which provides a set of rules to be allowed during the regression tests.
   You need to install this policy package using the <command>semodule</>
   command, which links supplied policy packages and loads them
   into the kernel space.  If this packages is correctly installed,
   <literal><command>semodule</> -l</> should list sepgsql-regtest as an
   available policy package.
  </para>

<screen>
$ su
# semodule -u /usr/local/pgsql/share/contrib/sepgsql-regtest.pp
# semodule -l
    :
sepgsql-regtest 1.03
    :
</screen>

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

<screen>
$ su
# setsebool sepgsql_regression_test_mode on
# getsebool sepgsql_regression_test_mode
sepgsql_regression_test_mode --> on
</screen>

  <para>
   Last, kick the regression test from the <literal>unconfined_t</> domain.
  </para>

  <para>
   The <command>id</> command tells us the current working domain.
   Confirm your shell is now performing with the <literal>unconfined_t</>
   domain as follows.
  </para>
<screen>
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
</screen>

  <para>
   See <xref linkend="sepgsql-resources"> for details on adjusting your
   working domain, if necessary.
  </para>

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

<screen>
$ restorecon -R /usr/local/pgsql/
</screen>
 </sect2>

 <sect2 id="sepgsql-parameters">
  <title>GUC Parameters</title>

  <variablelist>
   <varlistentry id="guc-sepgsql-permissive" xreflabel="sepgsql.permissive">
    <term><varname>sepgsql.permissive</> (<type>boolean</type>)</term>
    <indexterm>
     <primary><varname>sepgsql.permissive</> configuration parameter</primary>
    </indexterm>
    <listitem>
     <para>
      This parameter enables <productname>SE-PostgreSQL</> to function
      in permissive mode, regardless of the system setting.
      The default is off.
      This parameter can only be set in the <filename>postgresql.conf</>
      file or on the server command line.
     </para>

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

   </varlistentry>
   <varlistentry id="guc-sepgsql-debug-audit" xreflabel="sepgsql.debug_audit">
    <term><varname>sepgsql.debug_audit</> (<type>boolean</>)</>
    <indexterm>
     <primary><varname>sepgsql.debug_audit</> configuration parameter</>
    </indexterm>
    <listitem>
     <para>
      This parameter enables the printing of audit messages independent from
      the policy setting.
      The default is off (according to the security policy setting).
     </para>

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

     <para>
      This parameter forces all possible logging to be turned on, regardless
      of the system policy.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </sect2>

 <sect2 id="sepgsql-features">
  <title>Features</title>
  <sect3>
   <title>controlled object classes</title>
   <para>
    The security model of <productname>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
    <literal>unlabeled_t</>.
   </para>

   <para>
    Currently, <productname>sepgsql</productname> allows security labels to be
    assigned to schemas, tables, columns, sequences, views, and functions.
    When <productname>sepgsql</productname> is in use, security labels are
    automatically assigned to suppoted 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.
   </para>

   <para>
    A new database object basically inherits 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.
    The meaning of the term "parent object" varies by object class, as follows.
   </para>

   <variablelist>
    <varlistentry>
     <term>schema</term>
     <listitem>
      <para>
       The parent object is the current database.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>table</term>
     <listitem>
      <para>
       The parent object is the containing schema.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>column</term>
     <listitem>
      <para>
       The parent object is the table.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>sequence</term>
     <listitem>
      <para>
       The parent object is the containing schema.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>view</term>
     <listitem>
      <para>
       The parent object is the containing schema.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>function</term>
     <listitem>
      <para>
       Its parent object is the containing schema.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </sect3>
  <sect3>
   <title>DML Permissions</title>

   <para>
    This section introduces what permissions shall be checked on DML;
    <literal>SELECT</>, <literal>INSERT</>, <literal>UPDATE</> and
    <literal>DELETE</>.
   </para>

   <para>
    DML statements are used to reference or modify contents within
    the specified database objects; such as tables or columns.
    We basically checks access rights of the client on all the objects
    mentioned in the given statement, and the kind of privileges checked
    depend on the class of the object and the type of access.
   </para>

   <para>
    For tables, <literal>db_table:select</>, <literal>db_table:insert</>,
    <literal>db_table:update</> or <literal>db_table:delete</> is
    checked for all the appeared target tables depending on the sort of
    statement;
    in addition, <literal>db_table:select</> is also checked for
    all the tables that containin the columns to be referenced in
    <literal>WHERE</> or <literal>RETURNING</> clause, as a data source
    of <literal>UPDATE</>, and so on.
   </para>

   <para>
<synopsis>
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
</synopsis>

    In this case, we must have <literal>db_table:select</>, not only
    <literal>db_table:update</>, because <literal>t1.a</> is referenced
    within <literal>WHERE</> clause.  Column-level permissions will be
    checked as well, for each referenced column.
   </para>

   <para>
    The client must be allowed to reference all the appeared tables and
    columns, even if they are originated from views then expanded, because we
    intend to apply consistent access control rules independent from the
    manner in which the table contents are referenced.
   </para>

   <para>
    For columns, <literal>db_column:select</> is checked on
    not only the columns being read using <literal>SELECT</>, but being
    referenced in other DML statement.
   </para>

   <para>
    Of course, it also checks <literal>db_column:update</> or
    <literal>db_column:insert</> on the column being modified by
    <literal>UPDATE</> or <literal>INSERT</>.
   </para>

   <para>
<synopsis>
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
</synopsis>
    In this case, it checks <literal>db_column:update</> on
    the <literal>t1.x</> being updated, <literal>db_column:{select update}</>
    on the <literal>t1.y</> being updated and referenced,
    and <literal>db_column:select</> on the <literal>t1.z</> being only
    referenced in the <literal>WHERE</> clause.
    Also note that <literal>db_table:{select update}</> shall be checked
    in the table-level granularity.
   </para>

   <para>
    For sequences, <literal>db_sequence:get_value</> when we reference
    a sequence object using <literal>SELECT</>; however, note that we
    cannot check permissions on execution of corresponding functions
    such as <literal>lastval()</> right now, although they performs same
    job, because here is no object access hook to acquire controls.
   </para>

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

   <para>
    For functions, <literal>db_procedure:{execute}</> is defined, but not
    checked in this version.
   </para>

   <para>
    Here is a few more corner cases.
    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
    <productname>sepgsql</> is enabled.
   </para>
  </sect3>

  <sect3>
   <title>DDL Permissions</title>
   <para>
    On <xref linkend="sql-security-label"> command, <literal>setattr</> and
    <literal>relabelfrom</> shall be checked on the object being relabeled
    with an old security label, then <literal>relabelto</> on the supplied
    new security label.
   </para>

   <para>
    In a case when multiple label providers are installed and user tries
    to set a security label, but is not managed by <productname>SELinux</>,
    only <literal>setattr</> should be checked here.
    This is currently not done due to implementation restrictions.
   </para>
  </sect3>

  <sect3>
   <title>Trusted Procedure</title>
   <para>
    It is a similar idea to security definer functions or set-uid commands
    on operating systems. <productname>SELinux</> provides a feature to
    switch privilege of the client (that is a security label of the client
    for more correctness) during execution of certain functions; being
    called as trusted procedures.
   </para>

   <para>
    A trusted function is a function with a special security label being
    set up as a trusted procedure.
    So, we need to assign the special security label on the function that
    we hope it to perform as a trusted procedure, by administrative users.
    The default security policy also provides this special security label.
    See the following example.
   </para>

<screen>
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
</screen>

   <para>
    Above operations shall be done by administrative users.
   </para>

<screen>
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)
</screen>

   <para>
    In this case, a regular user cannot reference <literal>customer.credit</>
    directly, but a trusted procedure <literal>show_credit</> enables us
    to print credit number of customers with a bit modification.
   </para>
  </sect3>

  <sect3>
   <title>Miscellaneous</title>
   <para>
    In this version, we reject <xref linkend="sql-load"> command across
    the board, because any module loaded could easily circumvent security
    policy enforcement.
   </para>

  </sect3>
 </sect2>
 <sect2 id="sepgsql-limitations">
  <title>Limitations</title>

  <variablelist>
   <varlistentry>
    <term>Userspace access vector cache</term>
    <listitem>
     <para>
      <productname>sepgsql</> does not yet support an access vector cache.
      This would likely improve performance.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>Data Definition Language (DDL) Permissions</term>
    <listitem>
     <para>
      Due to implementation restrictions, DDL permissions are not checked.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>Data Control Language (DCL) Permissions</term>
    <listitem>
     <para>
      Due to implementation restrictions, DCL permissions are not checked.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>Row-level access control</term>
    <listitem>
     <para>
      <productname>PostgreSQL</> does not support row-level access; therefore,
      <productname>sepgsql</productname> does not support it either.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>Covert channels</term>
    <listitem>
     <para>
      <productname>sepgsql</> never tries to hide existence of
      a certain object, even if user is not allowed to reference.
      For example, we can infer an existence of invisible object using
      primary-key confliction, foreign-key violation, and so on, even if
      we cannot reference contents of these objects.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </sect2>

 <sect2 id="sepgsql-resources">
  <title>External Resources</title>
  <variablelist>
   <varlistentry>
    <term><ulink url="http://wiki.postgresql.org/wiki/SEPostgreSQL">SE-PostgreSQL Introduction</ulink></term>
    <listitem>
     <para>
      This wiki page provides a brief-overview, security design, architecture,
      administration and upcoming feature for more details.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term><ulink url="http://docs.fedoraproject.org/selinux-user-guide/">Fedora SELinux User Guide</ulink></term>
    <listitem>
     <para>
      This document provides wide spectrum of knowledge to administer
      <productname>SELinux</> on your systems.
      It primary focuses on Fedora, but is not limited to Fedora.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term><ulink url="http://docs.fedoraproject.org/selinux-faq">Fedora SELinux FAQ</ulink></term>
    <listitem>
     <para>
      This document answers frequently asked questins about
      <productname>SELinux</productname>.
      It primary focuses on Fedora, but is not limited to Fedora.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </sect2>

 <sect2 id="sepgsql-author">
  <title>Author</title>
  <para>
   KaiGai Kohei (<email>kaigai@ak.jp.nec.com</email>)
  </para>
 </sect2>
</sect1>