2011-01-24 02:44:48 +01:00
|
|
|
<!-- doc/src/sgml/sepgsql.sgml -->
|
|
|
|
|
2011-05-08 04:29:20 +02:00
|
|
|
<sect1 id="sepgsql" xreflabel="sepgsql">
|
2011-01-24 02:44:48 +01:00
|
|
|
<title>sepgsql</title>
|
|
|
|
|
|
|
|
<indexterm zone="sepgsql">
|
|
|
|
<primary>sepgsql</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<filename>sepgsql</filename> is a loadable module that supports label-based
|
|
|
|
mandatory access control (MAC) based on <productname>SELinux</productname> security
|
2011-02-03 06:23:44 +01:00
|
|
|
policy.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
|
2011-02-03 06:23:44 +01:00
|
|
|
<warning>
|
|
|
|
<para>
|
2011-09-28 02:07:15 +02:00
|
|
|
The current implementation has significant limitations, and does not
|
|
|
|
enforce mandatory access control for all actions. See
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sepgsql-limitations"/>.
|
2011-02-03 06:23:44 +01:00
|
|
|
</para>
|
|
|
|
</warning>
|
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<sect2 id="sepgsql-overview">
|
|
|
|
<title>Overview</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
This module integrates with <productname>SELinux</productname> to provide an
|
2011-05-19 00:14:45 +02:00
|
|
|
additional layer of security checking above and beyond what is normally
|
2011-01-24 04:47:16 +01:00
|
|
|
provided by <productname>PostgreSQL</productname>. From the perspective of
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>SELinux</productname>, this module allows
|
2011-01-24 04:47:16 +01:00
|
|
|
<productname>PostgreSQL</productname> to function as a user-space object
|
|
|
|
manager. Each table or function access initiated by a DML query will be
|
2011-09-28 02:07:15 +02:00
|
|
|
checked against the system security policy. This check is in addition to
|
|
|
|
the usual SQL permissions checking performed by
|
2011-01-24 04:47:16 +01:00
|
|
|
<productname>PostgreSQL</productname>.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-01-24 04:47:16 +01:00
|
|
|
<productname>SELinux</productname> access control decisions are made using
|
|
|
|
security labels, which are represented by strings such as
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>system_u:object_r:sepgsql_table_t:s0</literal>. Each access control
|
2011-01-24 04:47:16 +01:00
|
|
|
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
|
2011-09-28 02:07:15 +02:00
|
|
|
for objects of any other type, such as files. This design is intended to
|
2011-01-24 04:47:16 +01:00
|
|
|
allow a centralized security policy to protect information assets
|
|
|
|
independent of the particulars of how those assets are stored.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
|
|
|
The <link linkend="sql-security-label"><command>SECURITY LABEL</command></link> statement allows assignment of
|
2011-01-24 04:47:16 +01:00
|
|
|
a security label to a database object.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
</sect2>
|
|
|
|
<sect2 id="sepgsql-installation">
|
|
|
|
<title>Installation</title>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<filename>sepgsql</filename> can only be used on <productname>Linux</productname>
|
2011-09-28 02:07:15 +02:00
|
|
|
2.6.28 or higher with <productname>SELinux</productname> enabled.
|
|
|
|
It is not available on any other platform. You will also need
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>libselinux</productname> 2.1.10 or higher and
|
|
|
|
<productname>selinux-policy</productname> 3.9.13 or higher (although some
|
2011-09-28 02:07:15 +02:00
|
|
|
distributions may backport the necessary rules into older policy
|
2011-02-03 06:23:44 +01:00
|
|
|
versions).
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The <command>sestatus</command> command allows you to check the status of
|
2011-09-28 02:07:15 +02:00
|
|
|
<productname>SELinux</productname>. A typical display is:
|
2011-01-24 02:44:48 +01:00
|
|
|
<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>
|
2017-10-09 03:44:17 +02:00
|
|
|
If <productname>SELinux</productname> is disabled or not installed, you must set
|
2011-01-24 04:47:16 +01:00
|
|
|
that product up first before installing this module.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
To build this module, include the option <literal>--with-selinux</literal> in
|
|
|
|
your PostgreSQL <literal>configure</literal> command. Be sure that the
|
|
|
|
<filename>libselinux-devel</filename> RPM is installed at build time.
|
2011-09-28 02:07:15 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
To use this module, you must include <literal>sepgsql</literal>
|
2017-11-23 15:39:47 +01:00
|
|
|
in the <xref linkend="guc-shared-preload-libraries"/> parameter in
|
2017-10-09 03:44:17 +02:00
|
|
|
<filename>postgresql.conf</filename>. The module will not function correctly
|
2011-09-28 02:07:15 +02:00
|
|
|
if loaded in any other manner. Once the module is loaded, you
|
2011-02-03 06:23:44 +01:00
|
|
|
should execute <filename>sepgsql.sql</filename> in each database.
|
|
|
|
This will install functions needed for security label management, and
|
|
|
|
assign initial security labels.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-09-28 02:07:15 +02:00
|
|
|
Here is an example showing how to initialize a fresh database cluster
|
2017-10-09 03:44:17 +02:00
|
|
|
with <filename>sepgsql</filename> functions and security labels installed.
|
2011-09-28 02:07:15 +02:00
|
|
|
Adjust the paths shown as appropriate for your installation:
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<screen>
|
2011-09-28 02:07:15 +02:00
|
|
|
$ export PGDATA=/path/to/data/directory
|
2011-02-03 06:23:44 +01:00
|
|
|
$ initdb
|
2011-01-24 02:44:48 +01:00
|
|
|
$ vi $PGDATA/postgresql.conf
|
2011-09-28 02:07:15 +02:00
|
|
|
change
|
|
|
|
#shared_preload_libraries = '' # (change requires restart)
|
|
|
|
to
|
|
|
|
shared_preload_libraries = 'sepgsql' # (change requires restart)
|
2011-01-24 02:44:48 +01:00
|
|
|
$ for DBNAME in template0 template1 postgres; do
|
2011-09-28 02:07:15 +02:00
|
|
|
postgres --single -F -c exit_on_error=true $DBNAME \
|
|
|
|
</usr/local/pgsql/share/contrib/sepgsql.sql >/dev/null
|
2011-01-24 02:44:48 +01:00
|
|
|
done
|
|
|
|
</screen>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-07-20 15:22:57 +02:00
|
|
|
<para>
|
2011-09-23 23:02:46 +02:00
|
|
|
Please note that you may see some or all of the following notifications
|
2011-09-28 02:07:15 +02:00
|
|
|
depending on the particular versions you have of
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>libselinux</productname> and <productname>selinux-policy</productname>:
|
2011-07-20 15:22:57 +02:00
|
|
|
<screen>
|
|
|
|
/etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid object type db_blobs
|
2011-09-23 23:02:46 +02:00
|
|
|
/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
|
2011-07-20 15:22:57 +02:00
|
|
|
</screen>
|
2011-09-28 02:07:15 +02:00
|
|
|
These messages are harmless and should be ignored.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
If the installation process completes without error, you can now start the
|
|
|
|
server normally.
|
2011-07-20 15:22:57 +02:00
|
|
|
</para>
|
2011-01-24 02:44:48 +01:00
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2 id="sepgsql-regression">
|
|
|
|
<title>Regression Tests</title>
|
2011-09-28 02:07:15 +02:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-01-24 04:47:16 +01:00
|
|
|
Due to the nature of <productname>SELinux</productname>, running the
|
2017-10-09 03:44:17 +02:00
|
|
|
regression tests for <filename>sepgsql</filename> requires several extra
|
2011-09-28 02:07:15 +02:00
|
|
|
configuration steps, some of which must be done as root.
|
|
|
|
The regression tests will not be run by an ordinary
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>make check</literal> or <literal>make installcheck</literal> command; you must
|
2011-09-28 02:07:15 +02:00
|
|
|
set up the configuration and then invoke the test script manually.
|
2017-10-09 03:44:17 +02:00
|
|
|
The tests must be run in the <filename>contrib/sepgsql</filename> directory
|
2011-09-28 02:07:15 +02:00
|
|
|
of a configured PostgreSQL build tree. Although they require a build tree,
|
|
|
|
the tests are designed to be executed against an installed server,
|
2017-10-09 03:44:17 +02:00
|
|
|
that is they are comparable to <literal>make installcheck</literal> not
|
|
|
|
<literal>make check</literal>.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-09-28 02:07:15 +02:00
|
|
|
First, set up <filename>sepgsql</filename> in a working database
|
2017-11-23 15:39:47 +01:00
|
|
|
according to the instructions in <xref linkend="sepgsql-installation"/>.
|
2011-09-28 02:07:15 +02:00
|
|
|
Note that the current operating system user must be able to connect to the
|
|
|
|
database as superuser without password authentication.
|
2011-07-20 15:22:57 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Second, build and install the policy package for the regression test.
|
2017-10-09 03:44:17 +02:00
|
|
|
The <filename>sepgsql-regtest</filename> policy is a special purpose policy package
|
2011-01-24 04:47:16 +01:00
|
|
|
which provides a set of rules to be allowed during the regression tests.
|
2011-08-07 15:11:55 +02:00
|
|
|
It should be built from the policy source file
|
2017-10-09 03:44:17 +02:00
|
|
|
<filename>sepgsql-regtest.te</filename>, which is done using
|
2011-09-28 02:07:15 +02:00
|
|
|
<command>make</command> with a Makefile supplied by SELinux.
|
|
|
|
You will need to locate the appropriate
|
2011-02-17 12:39:13 +01:00
|
|
|
Makefile on your system; the path shown below is only an example.
|
2019-07-17 19:13:15 +02:00
|
|
|
(This Makefile is usually supplied by the
|
|
|
|
<filename>selinux-policy-devel</filename> or
|
|
|
|
<filename>selinux-policy</filename> RPM.)
|
2011-09-28 02:07:15 +02:00
|
|
|
Once built, install this policy package using the
|
2017-10-09 03:44:17 +02:00
|
|
|
<command>semodule</command> command, which loads supplied policy packages
|
2011-09-28 02:07:15 +02:00
|
|
|
into the kernel. If the package is correctly installed,
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal><command>semodule</command> -l</literal> should list <literal>sepgsql-regtest</literal> as an
|
2011-09-28 02:07:15 +02:00
|
|
|
available policy package:
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<screen>
|
2011-09-28 02:07:15 +02:00
|
|
|
$ cd .../contrib/sepgsql
|
|
|
|
$ make -f /usr/share/selinux/devel/Makefile
|
|
|
|
$ sudo semodule -u sepgsql-regtest.pp
|
|
|
|
$ sudo semodule -l | grep sepgsql
|
2013-04-17 15:55:24 +02:00
|
|
|
sepgsql-regtest 1.07
|
2011-01-24 02:44:48 +01:00
|
|
|
</screen>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Third, turn on <literal>sepgsql_regression_test_mode</literal>.
|
|
|
|
For security reasons, the rules in <filename>sepgsql-regtest</filename>
|
2012-03-15 21:37:40 +01:00
|
|
|
are not enabled by default;
|
|
|
|
the <literal>sepgsql_regression_test_mode</literal> parameter enables
|
2011-09-28 02:07:15 +02:00
|
|
|
the rules needed to launch the regression tests.
|
2017-10-09 03:44:17 +02:00
|
|
|
It can be turned on using the <command>setsebool</command> command:
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<screen>
|
2011-09-28 02:07:15 +02:00
|
|
|
$ sudo setsebool sepgsql_regression_test_mode on
|
|
|
|
$ getsebool sepgsql_regression_test_mode
|
2011-01-24 02:44:48 +01:00
|
|
|
sepgsql_regression_test_mode --> on
|
|
|
|
</screen>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Fourth, verify your shell is operating in the <literal>unconfined_t</literal>
|
2011-09-28 02:07:15 +02:00
|
|
|
domain:
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
<screen>
|
|
|
|
$ id -Z
|
|
|
|
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
|
|
|
|
</screen>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-11-23 15:39:47 +01:00
|
|
|
See <xref linkend="sepgsql-resources"/> for details on adjusting your
|
2011-01-24 04:47:16 +01:00
|
|
|
working domain, if necessary.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-09-28 02:07:15 +02:00
|
|
|
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
|
2017-10-09 03:44:17 +02:00
|
|
|
<filename>sepgsql</filename> module.
|
2011-09-28 02:07:15 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
After completing the tests, it's recommended you disable
|
|
|
|
the <literal>sepgsql_regression_test_mode</literal> parameter:
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<screen>
|
2011-09-28 02:07:15 +02:00
|
|
|
$ sudo setsebool sepgsql_regression_test_mode off
|
|
|
|
</screen>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
You might prefer to remove the <filename>sepgsql-regtest</filename> policy
|
2011-09-28 02:07:15 +02:00
|
|
|
entirely:
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<screen>
|
|
|
|
$ sudo semodule -r sepgsql-regtest
|
2011-01-24 02:44:48 +01:00
|
|
|
</screen>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2 id="sepgsql-parameters">
|
|
|
|
<title>GUC Parameters</title>
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry id="guc-sepgsql-permissive" xreflabel="sepgsql.permissive">
|
2014-05-07 03:28:58 +02:00
|
|
|
<term>
|
2017-10-09 03:44:17 +02:00
|
|
|
<varname>sepgsql.permissive</varname> (<type>boolean</type>)
|
2014-05-07 03:28:58 +02:00
|
|
|
<indexterm>
|
2017-10-09 03:44:17 +02:00
|
|
|
<primary><varname>sepgsql.permissive</varname> configuration parameter</primary>
|
2014-05-07 03:28:58 +02:00
|
|
|
</indexterm>
|
|
|
|
</term>
|
2011-01-24 02:44:48 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
This parameter enables <filename>sepgsql</filename> to function
|
2011-01-24 04:47:16 +01:00
|
|
|
in permissive mode, regardless of the system setting.
|
|
|
|
The default is off.
|
2017-10-09 03:44:17 +02:00
|
|
|
This parameter can only be set in the <filename>postgresql.conf</filename>
|
2011-01-24 02:44:48 +01:00
|
|
|
file or on the server command line.
|
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
When this parameter is on, <filename>sepgsql</filename> functions
|
2011-09-28 02:07:15 +02:00
|
|
|
in permissive mode, even if SELinux in general is working in enforcing
|
2011-01-24 04:47:16 +01:00
|
|
|
mode. This parameter is primarily useful for testing purposes.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
</varlistentry>
|
|
|
|
<varlistentry id="guc-sepgsql-debug-audit" xreflabel="sepgsql.debug_audit">
|
2014-05-07 03:28:58 +02:00
|
|
|
<term>
|
2017-10-09 03:44:17 +02:00
|
|
|
<varname>sepgsql.debug_audit</varname> (<type>boolean</type>)
|
2014-05-07 03:28:58 +02:00
|
|
|
<indexterm>
|
2017-10-09 03:44:17 +02:00
|
|
|
<primary><varname>sepgsql.debug_audit</varname> configuration parameter</primary>
|
2014-05-07 03:28:58 +02:00
|
|
|
</indexterm>
|
|
|
|
</term>
|
2011-01-24 02:44:48 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2011-09-28 02:07:15 +02:00
|
|
|
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.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The security policy of <productname>SELinux</productname> also has rules to
|
2011-01-24 04:47:16 +01:00
|
|
|
control whether or not particular accesses are logged.
|
|
|
|
By default, access violations are logged, but allowed
|
|
|
|
accesses are not.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-01-24 04:47:16 +01:00
|
|
|
This parameter forces all possible logging to be turned on, regardless
|
|
|
|
of the system policy.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2 id="sepgsql-features">
|
|
|
|
<title>Features</title>
|
2023-01-09 21:08:24 +01:00
|
|
|
<sect3 id="sepgsql-features-controlled-obj-classes">
|
2011-01-29 19:00:18 +01:00
|
|
|
<title>Controlled Object Classes</title>
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The security model of <productname>SELinux</productname> describes all the access
|
2011-09-28 02:07:15 +02:00
|
|
|
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
|
2013-05-21 03:13:13 +02:00
|
|
|
identified by a security label. If access to an unlabeled object is
|
2011-01-24 04:47:16 +01:00
|
|
|
attempted, the object is treated as if it were assigned the label
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>unlabeled_t</literal>.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-09-28 02:07:15 +02:00
|
|
|
Currently, <filename>sepgsql</filename> allows security labels to be
|
2011-01-24 04:47:16 +01:00
|
|
|
assigned to schemas, tables, columns, sequences, views, and functions.
|
2011-09-28 02:07:15 +02:00
|
|
|
When <filename>sepgsql</filename> is in use, security labels are
|
2011-01-24 14:42:44 +01:00
|
|
|
automatically assigned to supported database objects at creation time.
|
2011-09-28 02:07:15 +02:00
|
|
|
This label is called a default security label, and is decided according
|
2013-03-28 20:38:35 +01:00
|
|
|
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.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-01-24 14:42:44 +01:00
|
|
|
A new database object basically inherits the security label of the parent
|
2011-01-24 04:47:16 +01:00
|
|
|
object, except when the security policy has special rules known as
|
|
|
|
type-transition rules, in which case a different label may be applied.
|
2011-09-28 02:07:15 +02:00
|
|
|
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.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</sect3>
|
2011-02-03 06:23:44 +01:00
|
|
|
|
2023-01-09 21:08:24 +01:00
|
|
|
<sect3 id="sepgsql-features-dml-permissions">
|
2011-01-24 02:44:48 +01:00
|
|
|
<title>DML Permissions</title>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
For tables, <literal>db_table:select</literal>, <literal>db_table:insert</literal>,
|
|
|
|
<literal>db_table:update</literal> or <literal>db_table:delete</literal> are
|
2011-09-28 02:07:15 +02:00
|
|
|
checked for all the referenced target tables depending on the kind of
|
2017-10-09 03:44:17 +02:00
|
|
|
statement; in addition, <literal>db_table:select</literal> is also checked for
|
2012-02-15 15:57:56 +01:00
|
|
|
all the tables that contain columns referenced in the
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>WHERE</literal> or <literal>RETURNING</literal> clause, as a data source
|
|
|
|
for <literal>UPDATE</literal>, and so on.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2012-02-15 15:57:56 +01:00
|
|
|
Column-level permissions will also be checked for each referenced column.
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>db_column:select</literal> is checked on not only the columns being
|
|
|
|
read using <literal>SELECT</literal>, but those being referenced in other DML
|
|
|
|
statements; <literal>db_column:update</literal> or <literal>db_column:insert</literal>
|
|
|
|
will also be checked for columns being modified by <literal>UPDATE</literal> or
|
|
|
|
<literal>INSERT</literal>.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2012-02-15 15:57:56 +01:00
|
|
|
For example, consider:
|
2011-01-24 02:44:48 +01:00
|
|
|
<synopsis>
|
2018-02-07 03:59:40 +01:00
|
|
|
UPDATE t1 SET x = 2, y = func1(y) WHERE z = 100;
|
2011-01-24 02:44:48 +01:00
|
|
|
</synopsis>
|
2012-02-15 15:57:56 +01:00
|
|
|
|
2017-10-09 03:44:17 +02:00
|
|
|
Here, <literal>db_column:update</literal> will be checked for
|
|
|
|
<literal>t1.x</literal>, since it is being updated,
|
|
|
|
<literal>db_column:{select update}</literal> will be checked for
|
|
|
|
<literal>t1.y</literal>, since it is both updated and referenced, and
|
|
|
|
<literal>db_column:select</literal> will be checked for <literal>t1.z</literal>, since
|
2012-02-15 15:57:56 +01:00
|
|
|
it is only referenced.
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>db_table:{select update}</literal> will also be checked
|
2011-01-24 14:42:44 +01:00
|
|
|
at the table level.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
For sequences, <literal>db_sequence:get_value</literal> is checked when we
|
|
|
|
reference a sequence object using <literal>SELECT</literal>; however, note that we
|
2011-01-24 14:42:44 +01:00
|
|
|
do not currently check permissions on execution of corresponding functions
|
2017-10-09 03:44:17 +02:00
|
|
|
such as <literal>lastval()</literal>.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
For views, <literal>db_view:expand</literal> will be checked, then any other
|
2011-09-28 02:07:15 +02:00
|
|
|
required permissions will be checked on the objects being
|
2011-01-24 02:44:48 +01:00
|
|
|
expanded from the view, individually.
|
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
For functions, <literal>db_procedure:{execute}</literal> will be checked when
|
2013-04-12 14:55:56 +02:00
|
|
|
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
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>db_procedure:{entrypoint}</literal> permission to check whether it
|
2013-05-21 03:13:13 +02:00
|
|
|
can perform as entry point of trusted procedure.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2013-04-05 14:51:31 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
In order to access any schema object, <literal>db_schema:search</literal>
|
2013-04-05 14:51:31 +02:00
|
|
|
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
|
2017-10-09 03:44:17 +02:00
|
|
|
not have <literal>USAGE</literal> privilege on the schema). If an explicit schema
|
2013-04-05 14:51:31 +02:00
|
|
|
qualification is present, an error will occur if the user does not have
|
|
|
|
the requisite permission on the named schema.
|
|
|
|
</para>
|
|
|
|
|
2011-09-28 02:07:15 +02:00
|
|
|
<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>
|
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
|
|
|
The default database privilege system allows database superusers to
|
|
|
|
modify system catalogs using DML commands, and reference or modify
|
2011-01-24 04:47:16 +01:00
|
|
|
toast tables. These operations are prohibited when
|
2017-10-09 03:44:17 +02:00
|
|
|
<filename>sepgsql</filename> is enabled.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</sect3>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2023-01-09 21:08:24 +01:00
|
|
|
<sect3 id="sepgsql-features-ddl-permissions">
|
2011-01-24 02:44:48 +01:00
|
|
|
<title>DDL Permissions</title>
|
2011-12-21 15:12:43 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>SELinux</productname> defines several permissions to control common
|
2012-03-15 21:37:40 +01:00
|
|
|
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.
|
2011-12-21 15:12:43 +01:00
|
|
|
</para>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Creating a new database object requires <literal>create</literal> permission.
|
|
|
|
<productname>SELinux</productname> will grant or deny this permission based on the
|
2013-03-28 20:55:44 +01:00
|
|
|
client's security label and the proposed security label for the new
|
|
|
|
object. In some cases, additional privileges are required:
|
2011-12-21 15:12:43 +01:00
|
|
|
</para>
|
|
|
|
|
2013-03-28 20:55:44 +01:00
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
|
|
|
<link linkend="sql-createdatabase"><command>CREATE DATABASE</command></link> additionally requires
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>getattr</literal> permission for the source or template database.
|
2013-03-28 20:55:44 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Creating a schema object additionally requires <literal>add_name</literal>
|
2013-03-28 20:55:44 +01:00
|
|
|
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>
|
2017-10-09 03:44:17 +02:00
|
|
|
Creating a function marked as <literal>LEAKPROOF</literal> additionally
|
|
|
|
requires <literal>install</literal> permission. (This permission is also
|
|
|
|
checked when <literal>LEAKPROOF</literal> is set for an existing function.)
|
2013-03-28 20:55:44 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
|
2012-03-09 21:18:45 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
When <literal>DROP</literal> command is executed, <literal>drop</literal> will be
|
2013-03-28 20:55:44 +01:00
|
|
|
checked on the object being removed. Permissions will be also checked for
|
2017-10-09 03:44:17 +02:00
|
|
|
objects dropped indirectly via <literal>CASCADE</literal>. Deletion of objects
|
2013-03-28 20:55:44 +01:00
|
|
|
contained within a particular schema (tables, views, sequences and
|
2017-10-09 03:44:17 +02:00
|
|
|
procedures) additionally requires <literal>remove_name</literal> on the schema.
|
2012-03-09 21:18:45 +01:00
|
|
|
</para>
|
|
|
|
|
2012-10-23 23:07:26 +02:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
When <literal>ALTER</literal> command is executed, <literal>setattr</literal> will be
|
2013-03-28 20:55:44 +01:00
|
|
|
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:
|
2013-03-27 13:10:14 +01:00
|
|
|
</para>
|
|
|
|
|
2013-03-28 20:55:44 +01:00
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Moving an object to a new schema additionally requires
|
2017-10-09 03:44:17 +02:00
|
|
|
<literal>remove_name</literal> permission on the old schema and
|
|
|
|
<literal>add_name</literal> permission on the new one.
|
2013-03-28 20:55:44 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Setting the <literal>LEAKPROOF</literal> attribute on a function requires
|
|
|
|
<literal>install</literal> permission.
|
2013-03-28 20:55:44 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
|
|
|
Using <link linkend="sql-security-label"><command>SECURITY LABEL</command></link> on an object additionally
|
2017-10-09 03:44:17 +02:00
|
|
|
requires <literal>relabelfrom</literal> permission for the object in
|
|
|
|
conjunction with its old security label and <literal>relabelto</literal>
|
2013-03-28 20:55:44 +01:00
|
|
|
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
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>SELinux</productname>, only <literal>setattr</literal> should be checked here.
|
2013-03-28 20:55:44 +01:00
|
|
|
This is currently not done due to implementation restrictions.)
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
</sect3>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2023-01-09 21:08:24 +01:00
|
|
|
<sect3 id="sepgsql-features-trusted-procedures">
|
2011-09-28 02:07:15 +02:00
|
|
|
<title>Trusted Procedures</title>
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2012-06-07 23:06:20 +02:00
|
|
|
Trusted procedures are similar to security definer functions or setuid
|
2017-10-09 03:44:17 +02:00
|
|
|
commands. <productname>SELinux</productname> provides a feature to allow trusted
|
2011-01-24 14:42:44 +01:00
|
|
|
code to run using a security label different from that of the client,
|
|
|
|
generally for the purpose of providing highly controlled access to
|
2020-09-01 00:33:37 +02:00
|
|
|
sensitive data (e.g., rows might be omitted, or the precision of stored
|
2011-01-24 14:42:44 +01:00
|
|
|
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:
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<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>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2011-01-24 14:42:44 +01:00
|
|
|
The above operations should be performed by an administrative user.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<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>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
In this case, a regular user cannot reference <literal>customer.credit</literal>
|
|
|
|
directly, but a trusted procedure <literal>show_credit</literal> allows the user
|
2011-09-28 02:07:15 +02:00
|
|
|
to print the credit card numbers of customers with some of the digits
|
|
|
|
masked out.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</sect3>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2023-01-09 21:08:24 +01:00
|
|
|
<sect3 id="sepgsql-features-dynamic-domain-transitions">
|
2012-03-15 21:37:40 +01:00
|
|
|
<title>Dynamic Domain Transitions</title>
|
2012-03-15 21:08:40 +01:00
|
|
|
<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.
|
2017-10-09 03:44:17 +02:00
|
|
|
The client domain needs the <literal>setcurrent</literal> permission and also
|
|
|
|
<literal>dyntransition</literal> from the old to the new domain.
|
2012-03-15 21:08:40 +01:00
|
|
|
</para>
|
|
|
|
<para>
|
2012-03-15 21:37:40 +01:00
|
|
|
Dynamic domain transitions should be considered carefully, because they
|
2012-03-20 20:10:33 +01:00
|
|
|
allow users to switch their label, and therefore their privileges,
|
2012-03-15 21:37:40 +01:00
|
|
|
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:
|
2012-03-15 21:08:40 +01:00
|
|
|
</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');
|
2020-05-07 20:25:18 +02:00
|
|
|
sepgsql_setcon
|
2012-03-15 21:08:40 +01:00
|
|
|
----------------
|
|
|
|
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
|
2017-10-09 03:44:17 +02:00
|
|
|
range <literal>c1.c1023</literal> to the smaller range <literal>c1.c4</literal>, but
|
2012-03-15 21:37:40 +01:00
|
|
|
switching back was denied.
|
2012-03-15 21:08:40 +01:00
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
A combination of dynamic domain transition and trusted procedure
|
2012-03-15 21:49:44 +01:00
|
|
|
enables an interesting use case that fits the typical process life-cycle
|
|
|
|
of connection pooling software.
|
2012-03-15 21:08:40 +01:00
|
|
|
Even if your connection pooling software is not allowed to run most
|
2012-03-15 21:37:40 +01:00
|
|
|
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
|
2012-03-15 21:08:40 +01:00
|
|
|
credential to authorize the request to switch the client label.
|
2012-03-15 21:37:40 +01:00
|
|
|
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
|
2012-03-15 21:49:44 +01:00
|
|
|
credentials. Of course, for secure operation, the credential store
|
2012-03-15 21:37:40 +01:00
|
|
|
(table, procedure definition, or whatever) must be protected from
|
|
|
|
unauthorized access.
|
2012-03-15 21:08:40 +01:00
|
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
|
2023-01-09 21:08:24 +01:00
|
|
|
<sect3 id="sepgsql-features-misc">
|
2011-01-24 02:44:48 +01:00
|
|
|
<title>Miscellaneous</title>
|
|
|
|
<para>
|
Improve <xref> vs. <command> formatting in the documentation
SQL commands are generally marked up as <command>, except when a link
to a reference page is used using <xref>. But the latter doesn't
create monospace markup, so this looks strange especially when a
paragraph contains a mix of links and non-links.
We considered putting <command> in the <refentrytitle> on the target
side, but that creates some formatting side effects elsewhere.
Generally, it seems safer to solve this on the link source side.
We can't put the <xref> inside the <command>; the DTD doesn't allow
this. DocBook 5 would allow the <command> to have the linkend
attribute itself, but we are not there yet.
So to solve this for now, convert the <xref>s to <link> plus
<command>. This gives the correct look and also gives some more
flexibility what we can put into the link text (e.g., subcommands or
other clauses). In the future, these could then be converted to
DocBook 5 style.
I haven't converted absolutely all xrefs to SQL command reference
pages, only those where we care about the appearance of the link text
or where it was otherwise appropriate to make the appearance match a
bit better. Also in some cases, the links where repetitive, so in
those cases the links where just removed and replaced by a plain
<command>. In cases where we just want the link and don't
specifically care about the generated link text (typically phrased
"for further information see <xref ...>") the xref is kept.
Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
|
|
|
We reject the <link linkend="sql-load"><command>LOAD</command></link> command across the board, because
|
2011-02-03 06:23:44 +01:00
|
|
|
any module loaded could easily circumvent security policy enforcement.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
</sect3>
|
2012-03-15 21:08:40 +01:00
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2 id="sepgsql-functions">
|
|
|
|
<title>Sepgsql Functions</title>
|
|
|
|
<para>
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sepgsql-functions-table"/> shows the available functions.
|
2012-03-15 21:08:40 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<table id="sepgsql-functions-table">
|
|
|
|
<title>Sepgsql Functions</title>
|
2020-05-07 20:25:18 +02:00
|
|
|
<tgroup cols="1">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
Function
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Description
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
<function>sepgsql_getcon</function> ()
|
|
|
|
<returnvalue>text</returnvalue>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Returns the client domain, the current security label of the client.
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
<function>sepgsql_setcon</function> ( <type>text</type> )
|
|
|
|
<returnvalue>boolean</returnvalue>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
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.
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
<function>sepgsql_mcstrans_in</function> ( <type>text</type> )
|
|
|
|
<returnvalue>text</returnvalue>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Translates the given qualified MLS/MCS range into raw format if
|
|
|
|
the mcstrans daemon is running.
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
<function>sepgsql_mcstrans_out</function> ( <type>text</type> )
|
|
|
|
<returnvalue>text</returnvalue>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Translates the given raw MLS/MCS range into qualified format if
|
|
|
|
the mcstrans daemon is running.
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry role="func_table_entry"><para role="func_signature">
|
|
|
|
<function>sepgsql_restorecon</function> ( <type>text</type> )
|
|
|
|
<returnvalue>boolean</returnvalue>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Sets up initial security labels for all objects within the
|
|
|
|
current database. The argument may be <literal>NULL</literal>, or the
|
|
|
|
name of a specfile to be used as alternative of the system default.
|
|
|
|
</para></entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
2012-03-15 21:08:40 +01:00
|
|
|
</table>
|
2011-01-24 02:44:48 +01:00
|
|
|
</sect2>
|
2011-02-03 06:23:44 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<sect2 id="sepgsql-limitations">
|
|
|
|
<title>Limitations</title>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
2011-01-24 04:47:16 +01:00
|
|
|
<term>Data Definition Language (DDL) Permissions</term>
|
2011-01-24 02:44:48 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2012-03-15 21:37:40 +01:00
|
|
|
Due to implementation restrictions, some DDL operations do not
|
|
|
|
check permissions.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term>Data Control Language (DCL) Permissions</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2012-03-15 21:37:40 +01:00
|
|
|
Due to implementation restrictions, DCL operations do not check
|
|
|
|
permissions.
|
2011-01-24 04:47:16 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term>Row-level access control</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>PostgreSQL</productname> supports row-level access, but
|
2015-11-13 17:06:38 +01:00
|
|
|
<filename>sepgsql</filename> does not.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<varlistentry>
|
|
|
|
<term>Covert channels</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<filename>sepgsql</filename> does not try to hide the existence of
|
2011-09-28 02:07:15 +02:00
|
|
|
a certain object, even if the user is not allowed to reference it.
|
2011-01-24 14:42:44 +01:00
|
|
|
For example, we can infer the existence of an invisible object as
|
|
|
|
a result of primary key conflicts, foreign key violations, and so on,
|
2011-09-28 02:07:15 +02:00
|
|
|
even if we cannot obtain the contents of the object. The existence
|
2011-01-24 14:42:44 +01:00
|
|
|
of a top secret table cannot be hidden; we only hope to conceal its
|
|
|
|
contents.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</sect2>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<sect2 id="sepgsql-resources">
|
|
|
|
<title>External Resources</title>
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
2017-05-21 03:50:47 +02:00
|
|
|
<term><ulink url="https://wiki.postgresql.org/wiki/SEPostgreSQL">SE-PostgreSQL Introduction</ulink></term>
|
2011-01-24 02:44:48 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2011-09-28 02:07:15 +02:00
|
|
|
This wiki page provides a brief overview, security design, architecture,
|
2011-01-24 14:42:44 +01:00
|
|
|
administration and upcoming features.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
2021-10-28 02:25:55 +02:00
|
|
|
<term><ulink url="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index">SELinux User's and Administrator's Guide</ulink></term>
|
2011-01-24 02:44:48 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2011-01-24 14:42:44 +01:00
|
|
|
This document provides a wide spectrum of knowledge to administer
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>SELinux</productname> on your systems.
|
2017-09-18 17:09:15 +02:00
|
|
|
It focuses primarily on Red Hat operating systems, but is not limited to them.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
2017-09-18 17:09:15 +02:00
|
|
|
<term><ulink url="https://fedoraproject.org/wiki/SELinux_FAQ">Fedora SELinux FAQ</ulink></term>
|
2011-01-24 02:44:48 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2011-01-24 14:42:44 +01:00
|
|
|
This document answers frequently asked questions about
|
2011-01-24 04:47:16 +01:00
|
|
|
<productname>SELinux</productname>.
|
2011-01-24 14:42:44 +01:00
|
|
|
It focuses primarily on Fedora, but is not limited to Fedora.
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</sect2>
|
2011-01-24 04:47:16 +01:00
|
|
|
|
2011-01-24 02:44:48 +01:00
|
|
|
<sect2 id="sepgsql-author">
|
|
|
|
<title>Author</title>
|
|
|
|
<para>
|
2011-02-03 06:23:44 +01:00
|
|
|
KaiGai Kohei <email>kaigai@ak.jp.nec.com</email>
|
2011-01-24 02:44:48 +01:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|