794 lines
28 KiB
Plaintext
794 lines
28 KiB
Plaintext
<!-- doc/src/sgml/sepgsql.sgml -->
|
|
|
|
<sect1 id="sepgsql" xreflabel="sepgsql">
|
|
<title>sepgsql</title>
|
|
|
|
<indexterm zone="sepgsql">
|
|
<primary>sepgsql</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
<filename>sepgsql</> is a loadable module that supports label-based
|
|
mandatory access control (MAC) based on <productname>SELinux</> security
|
|
policy.
|
|
</para>
|
|
|
|
<warning>
|
|
<para>
|
|
The current implementation has significant limitations, and does not
|
|
enforce mandatory access control for all actions. See
|
|
<xref linkend="sepgsql-limitations">.
|
|
</para>
|
|
</warning>
|
|
|
|
<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 normally
|
|
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 in addition to
|
|
the usual SQL 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, such as 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>
|
|
<filename>sepgsql</> can only be used on <productname>Linux</productname>
|
|
2.6.28 or higher with <productname>SELinux</productname> enabled.
|
|
It is not available on any other platform. You will also need
|
|
<productname>libselinux</> 2.1.10 or higher and
|
|
<productname>selinux-policy</> 3.9.13 or higher (although some
|
|
distributions may backport the necessary rules into older policy
|
|
versions).
|
|
</para>
|
|
|
|
<para>
|
|
The <command>sestatus</> command allows you to check the status of
|
|
<productname>SELinux</productname>. A typical display is:
|
|
<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>
|
|
To build this module, include the option <literal>--with-selinux</> in
|
|
your PostgreSQL <literal>configure</> command. Be sure that the
|
|
<filename>libselinux-devel</> RPM is installed at build time.
|
|
</para>
|
|
|
|
<para>
|
|
To use this module, you must include <literal>sepgsql</>
|
|
in the <xref linkend="guc-shared-preload-libraries"> parameter in
|
|
<filename>postgresql.conf</>. The module will not function correctly
|
|
if loaded in any other manner. Once the module is loaded, you
|
|
should execute <filename>sepgsql.sql</filename> in each database.
|
|
This will install functions needed for security label management, and
|
|
assign initial security labels.
|
|
</para>
|
|
|
|
<para>
|
|
Here is an example showing how to initialize a fresh database cluster
|
|
with <filename>sepgsql</> functions and security labels installed.
|
|
Adjust the paths shown as appropriate for your installation:
|
|
</para>
|
|
|
|
<screen>
|
|
$ export PGDATA=/path/to/data/directory
|
|
$ initdb
|
|
$ vi $PGDATA/postgresql.conf
|
|
change
|
|
#shared_preload_libraries = '' # (change requires restart)
|
|
to
|
|
shared_preload_libraries = 'sepgsql' # (change requires restart)
|
|
$ for DBNAME in template0 template1 postgres; do
|
|
postgres --single -F -c exit_on_error=true $DBNAME \
|
|
</usr/local/pgsql/share/contrib/sepgsql.sql >/dev/null
|
|
done
|
|
</screen>
|
|
|
|
<para>
|
|
Please note that you may see some or all of the following notifications
|
|
depending on the particular versions you have of
|
|
<productname>libselinux</> and <productname>selinux-policy</>:
|
|
<screen>
|
|
/etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid object type db_blobs
|
|
/etc/selinux/targeted/contexts/sepgsql_contexts: line 36 has invalid object type db_language
|
|
/etc/selinux/targeted/contexts/sepgsql_contexts: line 37 has invalid object type db_language
|
|
/etc/selinux/targeted/contexts/sepgsql_contexts: line 38 has invalid object type db_language
|
|
/etc/selinux/targeted/contexts/sepgsql_contexts: line 39 has invalid object type db_language
|
|
/etc/selinux/targeted/contexts/sepgsql_contexts: line 40 has invalid object type db_language
|
|
</screen>
|
|
These messages are harmless and should be ignored.
|
|
</para>
|
|
|
|
<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 <filename>sepgsql</> requires several extra
|
|
configuration steps, some of which must be done as root.
|
|
The regression tests will not be run by an ordinary
|
|
<literal>make check</> or <literal>make installcheck</> command; you must
|
|
set up the configuration and then invoke the test script manually.
|
|
The tests must be run in the <filename>contrib/sepgsql</> directory
|
|
of a configured PostgreSQL build tree. Although they require a build tree,
|
|
the tests are designed to be executed against an installed server,
|
|
that is they are comparable to <literal>make installcheck</> not
|
|
<literal>make check</>.
|
|
</para>
|
|
|
|
<para>
|
|
First, set up <filename>sepgsql</filename> in a working database
|
|
according to the instructions in <xref linkend="sepgsql-installation">.
|
|
Note that the current operating system user must be able to connect to the
|
|
database as superuser without password authentication.
|
|
</para>
|
|
|
|
<para>
|
|
Second, build and install the policy package for the regression test.
|
|
The <filename>sepgsql-regtest</> policy 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
|
|
<filename>sepgsql-regtest.te</>, which is done using
|
|
<command>make</command> with a Makefile supplied by SELinux.
|
|
You will need to locate the appropriate
|
|
Makefile on your system; the path shown below is only an example.
|
|
Once built, install this policy package using the
|
|
<command>semodule</> command, which loads supplied policy packages
|
|
into the kernel. If the package is correctly installed,
|
|
<literal><command>semodule</> -l</> should list <literal>sepgsql-regtest</literal> as an
|
|
available policy package:
|
|
</para>
|
|
|
|
<screen>
|
|
$ cd .../contrib/sepgsql
|
|
$ make -f /usr/share/selinux/devel/Makefile
|
|
$ sudo semodule -u sepgsql-regtest.pp
|
|
$ sudo semodule -l | grep sepgsql
|
|
sepgsql-regtest 1.07
|
|
</screen>
|
|
|
|
<para>
|
|
Third, turn on <literal>sepgsql_regression_test_mode</>.
|
|
For security reasons, the rules in <filename>sepgsql-regtest</>
|
|
are not enabled by default;
|
|
the <literal>sepgsql_regression_test_mode</literal> parameter enables
|
|
the rules needed to launch the regression tests.
|
|
It can be turned on using the <command>setsebool</> command:
|
|
</para>
|
|
|
|
<screen>
|
|
$ sudo setsebool sepgsql_regression_test_mode on
|
|
$ getsebool sepgsql_regression_test_mode
|
|
sepgsql_regression_test_mode --> on
|
|
</screen>
|
|
|
|
<para>
|
|
Fourth, verify your shell is operating in the <literal>unconfined_t</>
|
|
domain:
|
|
</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>
|
|
Finally, run the regression test script:
|
|
</para>
|
|
<screen>
|
|
$ ./test_sepgsql
|
|
</screen>
|
|
|
|
<para>
|
|
This script will attempt to verify that you have done all the configuration
|
|
steps correctly, and then it will run the regression tests for the
|
|
<filename>sepgsql</> module.
|
|
</para>
|
|
|
|
<para>
|
|
After completing the tests, it's recommended you disable
|
|
the <literal>sepgsql_regression_test_mode</literal> parameter:
|
|
</para>
|
|
|
|
<screen>
|
|
$ sudo setsebool sepgsql_regression_test_mode off
|
|
</screen>
|
|
|
|
<para>
|
|
You might prefer to remove the <filename>sepgsql-regtest</> policy
|
|
entirely:
|
|
</para>
|
|
|
|
<screen>
|
|
$ sudo semodule -r sepgsql-regtest
|
|
</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>)
|
|
<indexterm>
|
|
<primary><varname>sepgsql.permissive</> configuration parameter</primary>
|
|
</indexterm>
|
|
</term>
|
|
<listitem>
|
|
<para>
|
|
This parameter enables <filename>sepgsql</> 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, <filename>sepgsql</> functions
|
|
in permissive mode, even if SELinux in general 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>
|
|
</term>
|
|
<listitem>
|
|
<para>
|
|
This parameter enables the printing of audit messages regardless of
|
|
the system policy settings.
|
|
The default is off, which means that messages will be printed according
|
|
to the system settings.
|
|
</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 relationships between a subject entity (typically,
|
|
a client of the database) and an object entity (such as a database
|
|
object), each of which is
|
|
identified by a security label. If access to an unlabeled object is
|
|
attempted, the object is treated as if it were assigned the label
|
|
<literal>unlabeled_t</>.
|
|
</para>
|
|
|
|
<para>
|
|
Currently, <filename>sepgsql</filename> allows security labels to be
|
|
assigned to schemas, tables, columns, sequences, views, and functions.
|
|
When <filename>sepgsql</filename> is in use, security labels are
|
|
automatically assigned to supported database objects at creation time.
|
|
This label is called a default security label, and is decided according
|
|
to the system security policy, which takes as input the creator's label,
|
|
the label assigned to the new object's parent object and optionally name
|
|
of the constructed object.
|
|
</para>
|
|
|
|
<para>
|
|
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 tables,
|
|
sequences, views, and functions, it is the containing schema; for columns,
|
|
it is the containing table.
|
|
</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>DML Permissions</title>
|
|
|
|
<para>
|
|
For tables, <literal>db_table:select</>, <literal>db_table:insert</>,
|
|
<literal>db_table:update</> or <literal>db_table:delete</> are
|
|
checked for all the referenced target tables depending on the kind of
|
|
statement; in addition, <literal>db_table:select</> is also checked for
|
|
all the tables that contain columns referenced in the
|
|
<literal>WHERE</> or <literal>RETURNING</> clause, as a data source
|
|
for <literal>UPDATE</>, and so on.
|
|
</para>
|
|
|
|
<para>
|
|
Column-level permissions will also be checked for each referenced column.
|
|
<literal>db_column:select</> is checked on not only the columns being
|
|
read using <literal>SELECT</>, but those being referenced in other DML
|
|
statements; <literal>db_column:update</> or <literal>db_column:insert</>
|
|
will also be checked for columns being modified by <literal>UPDATE</> or
|
|
<literal>INSERT</>.
|
|
</para>
|
|
|
|
<para>
|
|
For example, consider:
|
|
<synopsis>
|
|
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
|
|
</synopsis>
|
|
|
|
Here, <literal>db_column:update</> will be checked for
|
|
<literal>t1.x</>, since it is being updated,
|
|
<literal>db_column:{select update}</> will be checked for
|
|
<literal>t1.y</>, since it is both updated and referenced, and
|
|
<literal>db_column:select</> will be checked for <literal>t1.z</>, since
|
|
it is only referenced.
|
|
<literal>db_table:{select update}</> will also be checked
|
|
at the table level.
|
|
</para>
|
|
|
|
<para>
|
|
For sequences, <literal>db_sequence:get_value</> is checked when we
|
|
reference a sequence object using <literal>SELECT</>; however, note that we
|
|
do not currently check permissions on execution of corresponding functions
|
|
such as <literal>lastval()</>.
|
|
</para>
|
|
|
|
<para>
|
|
For views, <literal>db_view:expand</> will be checked, then any other
|
|
required permissions will be checked on the objects being
|
|
expanded from the view, individually.
|
|
</para>
|
|
|
|
<para>
|
|
For functions, <literal>db_procedure:{execute}</> will be checked when
|
|
user tries to execute a function as a part of query, or using fast-path
|
|
invocation. If this function is a trusted procedure, it also checks
|
|
<literal>db_procedure:{entrypoint}</> permission to check whether it
|
|
can perform as entry point of trusted procedure.
|
|
</para>
|
|
|
|
<para>
|
|
In order to access any schema object, <literal>db_schema:search</>
|
|
permission is required on the containing schema. When an object is
|
|
referenced without schema qualification, schemas on which this
|
|
permission is not present will not be searched (just as if the user did
|
|
not have <literal>USAGE</> privilege on the schema). If an explicit schema
|
|
qualification is present, an error will occur if the user does not have
|
|
the requisite permission on the named schema.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<filename>sepgsql</> is enabled.
|
|
</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>DDL Permissions</title>
|
|
<para>
|
|
<productname>SELinux</> defines several permissions to control common
|
|
operations for each object type; such as creation, alter, drop and
|
|
relabel of security label. In addition, several object types have
|
|
special permissions to control their characteristic operations; such as
|
|
addition or deletion of name entries within a particular schema.
|
|
</para>
|
|
<para>
|
|
Creating a new database object requires <literal>create</> permission.
|
|
<productname>SELinux</> will grant or deny this permission based on the
|
|
client's security label and the proposed security label for the new
|
|
object. In some cases, additional privileges are required:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<xref linkend="sql-createdatabase"> additionally requires
|
|
<literal>getattr</> permission for the source or template database.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Creating a schema object additionally requires <literal>add_name</>
|
|
permission on the parent schema.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Creating a table additionally requires permission to create each
|
|
individual table column, just as if each table column were a
|
|
separate top-level object.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Creating a function marked as <literal>LEAKPROOF</> additionally
|
|
requires <literal>install</> permission. (This permission is also
|
|
checked when <literal>LEAKPROOF</> is set for an existing function.)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
When <literal>DROP</> command is executed, <literal>drop</> will be
|
|
checked on the object being removed. Permissions will be also checked for
|
|
objects dropped indirectly via <literal>CASCADE</>. Deletion of objects
|
|
contained within a particular schema (tables, views, sequences and
|
|
procedures) additionally requires <literal>remove_name</> on the schema.
|
|
</para>
|
|
|
|
<para>
|
|
When <literal>ALTER</> command is executed, <literal>setattr</> will be
|
|
checked on the object being modified for each object types, except for
|
|
subsidiary objects such as the indexes or triggers of a table, where
|
|
permissions are instead checked on the parent object. In some cases,
|
|
additional permissions are required:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Moving an object to a new schema additionally requires
|
|
<literal>remove_name</> permission on the old schema and
|
|
<literal>add_name</> permission on the new one.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Setting the <literal>LEAKPROOF</> attribute on a function requires
|
|
<literal>install</> permission.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Using <xref linkend="sql-security-label"> on an object additionally
|
|
requires <literal>relabelfrom</> permission for the object in
|
|
conjunction with its old security label and <literal>relabelto</>
|
|
permission for the object in conjunction with its new security label.
|
|
(In cases where multiple label providers are installed and the user
|
|
tries to set a security label, but it is not managed by
|
|
<productname>SELinux</>, only <literal>setattr</> should be checked here.
|
|
This is currently not done due to implementation restrictions.)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Trusted Procedures</title>
|
|
<para>
|
|
Trusted procedures are similar to security definer functions or setuid
|
|
commands. <productname>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:
|
|
</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>
|
|
The above operations should be performed by an administrative user.
|
|
</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</> allows the user
|
|
to print the credit card numbers of customers with some of the digits
|
|
masked out.
|
|
</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Dynamic Domain Transitions</title>
|
|
<para>
|
|
It is possible to use SELinux's dynamic domain transition feature
|
|
to switch the security label of the client process, the client domain,
|
|
to a new context, if that is allowed by the security policy.
|
|
The client domain needs the <literal>setcurrent</> permission and also
|
|
<literal>dyntransition</> from the old to the new domain.
|
|
</para>
|
|
<para>
|
|
Dynamic domain transitions should be considered carefully, because they
|
|
allow users to switch their label, and therefore their privileges,
|
|
at their option, rather than (as in the case of a trusted procedure)
|
|
as mandated by the system.
|
|
Thus, the <literal>dyntransition</literal> permission is only considered
|
|
safe when used to switch to a domain with a smaller set of privileges than
|
|
the original one. For example:
|
|
</para>
|
|
<screen>
|
|
regression=# select sepgsql_getcon();
|
|
sepgsql_getcon
|
|
-------------------------------------------------------
|
|
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
|
|
(1 row)
|
|
|
|
regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c4');
|
|
sepgsql_setcon
|
|
----------------
|
|
t
|
|
(1 row)
|
|
|
|
regression=# SELECT sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0-s0:c1.c1023');
|
|
ERROR: SELinux: security policy violation
|
|
</screen>
|
|
<para>
|
|
In this example above we were allowed to switch from the larger MCS
|
|
range <literal>c1.c1023</> to the smaller range <literal>c1.c4</>, but
|
|
switching back was denied.
|
|
</para>
|
|
<para>
|
|
A combination of dynamic domain transition and trusted procedure
|
|
enables an interesting use case that fits the typical process life-cycle
|
|
of connection pooling software.
|
|
Even if your connection pooling software is not allowed to run most
|
|
of SQL commands, you can allow it to switch the security label
|
|
of the client using the <literal>sepgsql_setcon()</literal> function
|
|
from within a trusted procedure; that should take some
|
|
credential to authorize the request to switch the client label.
|
|
After that, this session will have the privileges of the target user,
|
|
rather than the connection pooler.
|
|
The connection pooler can later revert the security label change by
|
|
again using <literal>sepgsql_setcon()</literal> with
|
|
<literal>NULL</literal> argument, again invoked from within a trusted
|
|
procedure with appropriate permissions checks.
|
|
The point here is that only the trusted procedure actually has permission
|
|
to change the effective security label, and only does so when given proper
|
|
credentials. Of course, for secure operation, the credential store
|
|
(table, procedure definition, or whatever) must be protected from
|
|
unauthorized access.
|
|
</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Miscellaneous</title>
|
|
<para>
|
|
We reject the <xref linkend="sql-load"> command across the board, because
|
|
any module loaded could easily circumvent security policy enforcement.
|
|
</para>
|
|
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2 id="sepgsql-functions">
|
|
<title>Sepgsql Functions</title>
|
|
<para>
|
|
<xref linkend="sepgsql-functions-table"> shows the available functions.
|
|
</para>
|
|
|
|
<table id="sepgsql-functions-table">
|
|
<title>Sepgsql Functions</title>
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>sepgsql_getcon() returns text</literal></entry>
|
|
<entry>
|
|
Returns the client domain, the current security label of the client.
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>sepgsql_setcon(text) returns bool</literal></entry>
|
|
<entry>
|
|
Switches the client domain of the current session to the new domain,
|
|
if allowed by the security policy.
|
|
It also accepts <literal>NULL</literal> input as a request to transition
|
|
to the client's original domain.
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>sepgsql_mcstrans_in(text) returns text</literal></entry>
|
|
<entry>Translates the given qualified MLS/MCS range into raw format if
|
|
the mcstrans daemon is running.
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>sepgsql_mcstrans_out(text) returns text</literal></entry>
|
|
<entry>Translates the given raw MLS/MCS range into qualified format if
|
|
the mcstrans daemon is running.
|
|
</entry>
|
|
</row>
|
|
<row>
|
|
<entry><literal>sepgsql_restorecon(text) returns bool</literal></entry>
|
|
<entry>
|
|
Sets up initial security labels for all objects within the
|
|
current database. The argument may be NULL, or the name of a specfile
|
|
to be used as alternative of the system default.
|
|
</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
|
|
<sect2 id="sepgsql-limitations">
|
|
<title>Limitations</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Data Definition Language (DDL) Permissions</term>
|
|
<listitem>
|
|
<para>
|
|
Due to implementation restrictions, some DDL operations do not
|
|
check permissions.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Data Control Language (DCL) Permissions</term>
|
|
<listitem>
|
|
<para>
|
|
Due to implementation restrictions, DCL operations do not check
|
|
permissions.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Row-level access control</term>
|
|
<listitem>
|
|
<para>
|
|
<productname>PostgreSQL</> supports row-level access, but
|
|
<filename>sepgsql</filename> does not.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Covert channels</term>
|
|
<listitem>
|
|
<para>
|
|
<filename>sepgsql</> does not try to hide the existence of
|
|
a certain object, even if the user is not allowed to reference it.
|
|
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 obtain the contents of the object. The existence
|
|
of a top secret table cannot be hidden; we only hope to conceal its
|
|
contents.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect2>
|
|
|
|
<sect2 id="sepgsql-resources">
|
|
<title>External Resources</title>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><ulink url="https://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 features.
|
|
</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 a wide spectrum of knowledge to administer
|
|
<productname>SELinux</> on your systems.
|
|
It focuses primarily 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 questions about
|
|
<productname>SELinux</productname>.
|
|
It focuses primarily 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>
|