mirror of
https://github.com/postgres/postgres.git
synced 2025-04-25 21:42:33 +03:00
Take sepgsql regression tests out of the regular regression test mechanism.
Back-port the new "test_sepgsql" script into 9.1 to provide a substitute test mechanism.
This commit is contained in:
Tom Lane
parent
1679e9fedd
commit
39be695772
@ -5,10 +5,9 @@ OBJS = hooks.o selinux.o label.o dml.o \
|
||||
schema.o relation.o proc.o
|
||||
DATA_built = sepgsql.sql
|
||||
|
||||
REGRESS = label dml misc
|
||||
REGRESS_OPTS = --launcher $(top_builddir)/contrib/sepgsql/launcher
|
||||
|
||||
EXTRA_CLEAN = -r tmp *.pp sepgsql-regtest.if sepgsql-regtest.fc
|
||||
# Note: because we don't tell the Makefile there are any regression tests,
|
||||
# we have to clean those result files explicitly
|
||||
EXTRA_CLEAN = -r $(pg_regress_clean_files) tmp/ *.pp sepgsql-regtest.if sepgsql-regtest.fc
|
||||
|
||||
ifdef USE_PGXS
|
||||
PG_CONFIG = pg_config
|
||||
|
||||
264
contrib/sepgsql/test_sepgsql
Executable file
264
contrib/sepgsql/test_sepgsql
Executable file
@ -0,0 +1,264 @@
|
||||
#!/bin/sh
|
||||
#
|
||||
# Run the sepgsql regression tests, after making a lot of environmental checks
|
||||
# to try to ensure that the SELinux environment is set up appropriately and
|
||||
# the database is configured correctly.
|
||||
#
|
||||
# Note that this must be run against an installed Postgres database.
|
||||
# There's no equivalent of "make check", and that wouldn't be terribly useful
|
||||
# since much of the value is in checking that you installed sepgsql into
|
||||
# your database correctly.
|
||||
#
|
||||
# This must be run in the contrib/sepgsql directory of a Postgres build tree.
|
||||
#
|
||||
|
||||
PG_BINDIR=`pg_config --bindir`
|
||||
|
||||
echo
|
||||
echo "============== checking selinux environment =============="
|
||||
|
||||
# matchpathcon must be present to assess whether the installation environment
|
||||
# is OK.
|
||||
echo -n "checking for matchpathcon ... "
|
||||
if ! matchpathcon -n . >/dev/null 2>&1; then
|
||||
echo "not found"
|
||||
echo ""
|
||||
echo "The matchpathcon command must be available."
|
||||
echo "Please install it or update your PATH to include it"
|
||||
echo "(it is typically in '/usr/sbin', which might not be in your PATH)."
|
||||
echo "matchpathcon is typically included in the libselinux-utils package."
|
||||
exit 1
|
||||
fi
|
||||
echo "ok"
|
||||
|
||||
# runcon must be present to launch psql using the correct environment
|
||||
echo -n "checking for runcon ... "
|
||||
if ! runcon --help >/dev/null 2>&1; then
|
||||
echo "not found"
|
||||
echo ""
|
||||
echo "The runcon command must be available."
|
||||
echo "runcon is typically included in the coreutils package."
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
echo "ok"
|
||||
|
||||
# check sestatus too, since that lives in yet another package
|
||||
echo -n "checking for sestatus ... "
|
||||
if ! sestatus >/dev/null 2>&1; then
|
||||
echo "not found"
|
||||
echo ""
|
||||
echo "The sestatus command must be available."
|
||||
echo "sestatus is typically included in the policycoreutils package."
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
echo "ok"
|
||||
|
||||
# check that the user is running in the unconfined_t domain
|
||||
echo -n "checking current user domain ... "
|
||||
DOMAIN=`id -Z 2>/dev/null | sed 's/:/ /g' | awk '{print $3}'`
|
||||
echo ${DOMAIN:-failed}
|
||||
if [ "${DOMAIN}" != unconfined_t ]; then
|
||||
echo ""
|
||||
echo "The regression tests must be launched from the unconfined_t domain."
|
||||
echo ""
|
||||
echo "The unconfined_t domain is typically the default domain for user"
|
||||
echo "shell processes. If the default has been changed on your system,"
|
||||
echo "you can revert the changes like this:"
|
||||
echo ""
|
||||
echo " \$ sudo semanage login -d `whoami`"
|
||||
echo ""
|
||||
echo "Or, you can add a setting to log in using the unconfined_t domain:"
|
||||
echo ""
|
||||
echo " \$ sudo semanage login -a -s unconfined_u -r s0-s0:c0.c255 `whoami`"
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# SELinux must be configured in enforcing mode
|
||||
echo -n "checking selinux operating mode ... "
|
||||
CURRENT_MODE=`LANG=C sestatus | grep '^Current mode:' | awk '{print $3}'`
|
||||
echo ${CURRENT_MODE:-failed}
|
||||
if [ "${CURRENT_MODE}" = enforcing ]; then
|
||||
: OK
|
||||
elif [ "${CURRENT_MODE}" = permissive -o "${CURRENT_MODE}" = disabled ]; then
|
||||
echo ""
|
||||
echo "Before running the regression tests, SELinux must be enabled and"
|
||||
echo "must be running in enforcing mode."
|
||||
echo ""
|
||||
echo "If SELinux is currently running in permissive mode, you can"
|
||||
echo "switch to enforcing mode using the 'setenforce' command."
|
||||
echo
|
||||
echo " \$ sudo setenforce 1"
|
||||
echo ""
|
||||
echo "The system default setting is configured in /etc/selinux/config,"
|
||||
echo "or using a kernel boot parameter."
|
||||
echo ""
|
||||
exit 1
|
||||
else
|
||||
echo ""
|
||||
echo "Unable to determine the current selinux operating mode. Please"
|
||||
echo "verify that the sestatus command is installed and in your PATH."
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 'sepgsql-regtest' policy module must be loaded
|
||||
echo -n "checking for sepgsql-regtest policy ... "
|
||||
SELINUX_MNT=`LANG=C sestatus | grep '^SELinuxfs mount:' | awk '{print $3}'`
|
||||
if [ "$SELINUX_MNT" = "" ]; then
|
||||
echo "failed"
|
||||
echo ""
|
||||
echo "Unable to find SELinuxfs mount point."
|
||||
echo ""
|
||||
echo "The sestatus command should report the location where SELinuxfs"
|
||||
echo "is mounted, but did not do so."
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
if [ ! -e "${SELINUX_MNT}/booleans/sepgsql_regression_test_mode" ]; then
|
||||
echo "failed"
|
||||
echo ""
|
||||
echo "The 'sepgsql-regtest' policy module appears not to be installed."
|
||||
echo "Without this policy installed, the regression tests will fail."
|
||||
echo "You can install this module using the following commands:"
|
||||
echo ""
|
||||
echo " \$ make -f /usr/share/selinux/devel/Makefile"
|
||||
echo " \$ sudo semodule -u sepgsql-regtest.pp"
|
||||
echo ""
|
||||
echo "To confirm that the policy package is installed, use this command:"
|
||||
echo ""
|
||||
echo " \$ sudo semodule -l | grep sepgsql"
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
echo "ok"
|
||||
|
||||
# Verify that sepgsql_regression_test_mode is active.
|
||||
echo -n "checking whether policy is enabled ... "
|
||||
POLICY_STATUS=`getsebool sepgsql_regression_test_mode | awk '{print $3}'`
|
||||
echo ${POLICY_STATUS:-failed}
|
||||
if [ "${POLICY_STATUS}" != on ]; then
|
||||
echo ""
|
||||
echo "The SELinux boolean 'sepgsql_regression_test_mode' must be"
|
||||
echo "turned on in order to enable the rules necessary to run the"
|
||||
echo "regression tests."
|
||||
echo ""
|
||||
if [ "${POLICY_STATUS}" = "" ]; then
|
||||
echo "We attempted to determine the state of this Boolean using"
|
||||
echo "'getsebool', but that command did not produce the expected"
|
||||
echo "output. Please verify that getsebool is available and in"
|
||||
echo "your PATH."
|
||||
else
|
||||
echo "You can turn on this variable using the following commands:"
|
||||
echo ""
|
||||
echo " \$ sudo setsebool sepgsql_regression_test_mode on"
|
||||
echo ""
|
||||
echo "For security reasons, it is suggested that you turn off this"
|
||||
echo "variable when regression testing is complete and the associated"
|
||||
echo "rules are no longer needed."
|
||||
fi
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 'psql' command must be executable from test domain
|
||||
echo -n "checking whether we can run psql ... "
|
||||
CMD_PSQL="${PG_BINDIR}/psql"
|
||||
if [ ! -e "${CMD_PSQL}" ]; then
|
||||
echo "not found"
|
||||
echo
|
||||
echo "${CMD_PSQL} was not found."
|
||||
echo "Check your PostgreSQL installation."
|
||||
echo
|
||||
exit 1
|
||||
fi
|
||||
runcon -t sepgsql_regtest_user_t "${CMD_PSQL}" --help >& /dev/null
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "failed"
|
||||
echo
|
||||
echo "${CMD_PSQL} must be executable from the"
|
||||
echo "sepgsql_regtest_user_t domain. That domain has restricted privileges"
|
||||
echo "compared to unconfined_t, so the problem may be the psql file's"
|
||||
echo "SELinux label. Try"
|
||||
echo
|
||||
PSQL_T=`matchpathcon -n "${CMD_PSQL}" | sed 's/:/ /g' | awk '{print $3}'`
|
||||
if [ "${PSQL_T}" = "user_home_t" ]; then
|
||||
# Installation appears to be in /home directory
|
||||
echo " \$ sudo restorecon -R ${PG_BINDIR}"
|
||||
echo
|
||||
echo "Or, using chcon"
|
||||
echo
|
||||
echo " \$ sudo chcon -t user_home_t ${CMD_PSQL}"
|
||||
else
|
||||
echo " \$ sudo restorecon -R ${PG_BINDIR}"
|
||||
echo
|
||||
echo "Or, using chcon"
|
||||
echo
|
||||
echo " \$ sudo chcon -t bin_t ${CMD_PSQL}"
|
||||
fi
|
||||
echo
|
||||
exit 1
|
||||
fi
|
||||
echo "ok"
|
||||
|
||||
# loadable module must be installed and not configured to permissive mode
|
||||
echo -n "checking sepgsql installation ... "
|
||||
VAL="`${CMD_PSQL} -t -c 'SHOW sepgsql.permissive' template1 2>/dev/null`"
|
||||
RETVAL="$?"
|
||||
if [ $RETVAL -eq 2 ]; then
|
||||
echo "failed"
|
||||
echo ""
|
||||
echo "Could not connect to the database server."
|
||||
echo "Please check your PostgreSQL installation."
|
||||
echo ""
|
||||
exit 1
|
||||
elif [ $RETVAL -ne 0 ]; then
|
||||
echo "failed"
|
||||
echo ""
|
||||
echo "The sepgsql module does not appear to be loaded. Please verify"
|
||||
echo "that the 'shared_preload_libraries' setting in postgresql.conf"
|
||||
echo "includes 'sepgsql', and then restart the server."
|
||||
echo ""
|
||||
echo "See Installation section of the contrib/sepgsql documentation."
|
||||
echo ""
|
||||
exit 1
|
||||
elif ! echo "$VAL" | grep -q 'off$'; then
|
||||
echo "failed"
|
||||
echo ""
|
||||
echo "The parameter 'sepgsql.permissive' is set to 'on'. It must be"
|
||||
echo "turned off before running the regression tests."
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
echo "ok"
|
||||
|
||||
# template1 database must be labeled
|
||||
# NOTE: this test is wrong; we really ought to be checking template0.
|
||||
# But we can't connect to that without extra pushups, and it's not worth it.
|
||||
echo -n "checking for labels in template1 ... "
|
||||
NUM=`${CMD_PSQL} -At -c 'SELECT count(*) FROM pg_catalog.pg_seclabel' template1 2>/dev/null`
|
||||
if [ -z "${NUM}" ]; then
|
||||
echo "failed"
|
||||
echo ""
|
||||
echo "In order to test sepgsql, initial labels must be assigned within"
|
||||
echo "the 'template1' database. These labels will be copied into the"
|
||||
echo "regression test database."
|
||||
echo ""
|
||||
echo "See Installation section of the contrib/sepgsql documentation."
|
||||
echo ""
|
||||
exit 1
|
||||
fi
|
||||
echo "found ${NUM}"
|
||||
|
||||
#
|
||||
# checking complete - let's run the tests
|
||||
#
|
||||
|
||||
echo
|
||||
echo "============== running sepgsql regression tests =============="
|
||||
|
||||
make REGRESS="label dml misc" REGRESS_OPTS="--launcher ./launcher" installcheck
|
||||
|
||||
# exit with the exit code provided by "make"
|
||||
@ -8,15 +8,15 @@
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<filename>sepgsql</> is a loadable module which supports label-based
|
||||
<filename>sepgsql</> is a loadable module that supports label-based
|
||||
mandatory access control (MAC) based on <productname>SELinux</> security
|
||||
policy.
|
||||
</para>
|
||||
|
||||
<warning>
|
||||
<para>
|
||||
This implementation has signification limitations, and does not enforce
|
||||
mandatory access control for all actions. See
|
||||
The current implementation has significant limitations, and does not
|
||||
enforce mandatory access control for all actions. See
|
||||
<xref linkend="sepgsql-limitations">.
|
||||
</para>
|
||||
</warning>
|
||||
@ -31,8 +31,8 @@
|
||||
<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
|
||||
checked against the system security policy. This check is in addition to
|
||||
the usual SQL permissions checking performed by
|
||||
<productname>PostgreSQL</productname>.
|
||||
</para>
|
||||
|
||||
@ -45,7 +45,7 @@
|
||||
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
|
||||
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>
|
||||
@ -60,18 +60,18 @@
|
||||
<title>Installation</title>
|
||||
|
||||
<para>
|
||||
This module 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, and must be explicitly enabled using
|
||||
<literal>--with-selinux</>. You will also need <productname>libselinux</>
|
||||
2.0.93 or higher and <productname>selinux-policy</> 3.9.13 or higher
|
||||
(some distributions may backport the necessary rules into older policy
|
||||
<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.0.93 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>.
|
||||
<productname>SELinux</productname>. A typical display is:
|
||||
<screen>
|
||||
$ sestatus
|
||||
SELinux status: enabled
|
||||
@ -86,112 +86,128 @@ Policy from config file: targeted
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To use this module, you must add include <literal>sepgsql</>
|
||||
in <xref linkend="guc-shared-preload-libraries">. The module will not
|
||||
function if loaded in any other manner. Once the module is loaded, you
|
||||
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>
|
||||
The following instructions that assume your installation is under the
|
||||
<filename>/usr/local/pgsql</> directory and the database cluster is
|
||||
under the <filename>/path/to/database</> directory. Adjust the paths
|
||||
shown below as appropriate for your installation.
|
||||
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/database
|
||||
$ 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 -O -c exit_on_error=true $DBNAME \
|
||||
< /usr/local/pgsql/share/contrib/sepgsql.sql > /dev/null
|
||||
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>
|
||||
|
||||
<para>
|
||||
Please note that you may see the following notifications depending on
|
||||
the combination of a particular version of <productname>libselinux</>
|
||||
and <productname>selinux-policy</>.
|
||||
<screen>
|
||||
/etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid object type db_blobs
|
||||
</screen>
|
||||
This message is harmless and may be safely ignored.
|
||||
</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.
|
||||
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 <productname>sepgsql</productname> according to
|
||||
the <xref linkend="sepgsql-installation">. The regression test is
|
||||
intended to be run on a system with a working SE-Linux implementation.
|
||||
The current operating system user must be able to connect to the database
|
||||
as superuser without authentication.
|
||||
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.pp</> is a special purpose policy package
|
||||
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 normally done using
|
||||
<command>make</command>. You will need to locate the appropriate
|
||||
<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, you can install this policy package using the
|
||||
<command>semodule</> command, which links supplied policy packages and
|
||||
loads them into the kernel space. If this package is correctly installed,
|
||||
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 sepgsql-regtest as an
|
||||
available policy package.
|
||||
available policy package:
|
||||
</para>
|
||||
|
||||
<screen>
|
||||
$ make -C ./contrib/sepgsql -f /usr/share/selinux/devel/Makefile
|
||||
$ su
|
||||
# semodule -u ./contrib/sepgsql/sepgsql-regtest.pp
|
||||
# semodule -l
|
||||
:
|
||||
$ cd .../contrib/sepgsql
|
||||
$ make -f /usr/share/selinux/devel/Makefile
|
||||
$ sudo semodule -u sepgsql-regtest.pp
|
||||
$ sudo semodule -l | grep sepgsql
|
||||
sepgsql-regtest 1.03
|
||||
:
|
||||
</screen>
|
||||
|
||||
<para>
|
||||
Third, turn on <literal>sepgsql_regression_test_mode</>.
|
||||
We don't enable all the rules in the <filename>sepgsql-regtest.pp</>
|
||||
We don't enable all the rules in <filename>sepgsql-regtest</>
|
||||
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.
|
||||
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>
|
||||
$ su
|
||||
# setsebool sepgsql_regression_test_mode on
|
||||
# getsebool sepgsql_regression_test_mode
|
||||
$ sudo 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.
|
||||
Fourth, verify your shell is operating in the <literal>unconfined_t</>
|
||||
domain:
|
||||
</para>
|
||||
<screen>
|
||||
$ id -Z
|
||||
@ -204,15 +220,34 @@ unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
|
||||
</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.
|
||||
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>
|
||||
$ restorecon -R /usr/local/pgsql/
|
||||
$ 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>
|
||||
|
||||
@ -227,7 +262,7 @@ $ restorecon -R /usr/local/pgsql/
|
||||
</indexterm>
|
||||
<listitem>
|
||||
<para>
|
||||
This parameter enables <productname>SE-PostgreSQL</> to function
|
||||
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</>
|
||||
@ -235,8 +270,8 @@ $ restorecon -R /usr/local/pgsql/
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When this parameter is on, <productname>SE-PostgreSQL</> functions
|
||||
in permissive mode, even if the platform system is working in enforcing
|
||||
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>
|
||||
@ -249,9 +284,10 @@ $ restorecon -R /usr/local/pgsql/
|
||||
</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).
|
||||
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>
|
||||
@ -276,19 +312,20 @@ $ restorecon -R /usr/local/pgsql/
|
||||
<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
|
||||
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 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
|
||||
Currently, <filename>sepgsql</filename> allows security labels to be
|
||||
assigned to schemas, tables, columns, sequences, views, and functions.
|
||||
When <productname>sepgsql</productname> is in use, security labels are
|
||||
When <filename>sepgsql</filename> is in use, security labels are
|
||||
automatically assigned to supported database objects at creation time.
|
||||
This label is called as a default security label, being decided according
|
||||
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
|
||||
and the label assigned to the new object's parent object.
|
||||
</para>
|
||||
@ -297,9 +334,9 @@ $ restorecon -R /usr/local/pgsql/
|
||||
A new database object basically inherits the security label of the parent
|
||||
object, except when the security policy has special rules known as
|
||||
type-transition rules, in which case a different label may be applied.
|
||||
For schemas, the parent object is the current database; for columns, it
|
||||
is the corresponding table; for tables, sequences, views, and functions,
|
||||
it is the containing schema.
|
||||
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>
|
||||
|
||||
@ -309,41 +346,29 @@ $ restorecon -R /usr/local/pgsql/
|
||||
<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 referenced target tables depending on the sort of
|
||||
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 the columns referenced in the
|
||||
<literal>WHERE</> or <literal>RETURNING</> clause, as a data source
|
||||
of <literal>UPDATE</>, and so on.
|
||||
</para>
|
||||
of <literal>UPDATE</>, and so on. For example, consider:
|
||||
|
||||
<para>
|
||||
<synopsis>
|
||||
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
|
||||
</synopsis>
|
||||
|
||||
In this case, we must have <literal>db_table:select</> in addition to
|
||||
In this case we must have <literal>db_table:select</> in addition to
|
||||
<literal>db_table:update</>, because <literal>t1.a</> is referenced
|
||||
within the <literal>WHERE</> clause. Column-level permissions will also be
|
||||
checked for each referenced column.
|
||||
</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>
|
||||
For columns, <literal>db_column:select</> is checked on
|
||||
not only the columns being read using <literal>SELECT</>, but being
|
||||
not only the columns being read using <literal>SELECT</>, but those being
|
||||
referenced in other DML statements.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Of course, it also checks <literal>db_column:update</> or
|
||||
<literal>db_column:insert</> on the column being modified by
|
||||
<literal>db_column:insert</> on columns being modified by
|
||||
<literal>UPDATE</> or <literal>INSERT</>.
|
||||
</para>
|
||||
|
||||
@ -351,11 +376,11 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
|
||||
<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.
|
||||
In this case, it checks <literal>db_column:update</> on the column
|
||||
<literal>t1.x</> being updated, <literal>db_column:{select update}</>
|
||||
on the column <literal>t1.y</> being updated and referenced, and
|
||||
<literal>db_column:select</> on the column <literal>t1.z</>, since that is
|
||||
only referenced in the <literal>WHERE</> clause.
|
||||
<literal>db_table:{select update}</> will also be checked
|
||||
at the table level.
|
||||
</para>
|
||||
@ -368,43 +393,50 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For views, <literal>db_view:expand</> shall be checked, then any other
|
||||
corresponding permissions shall be also checked on the objects being
|
||||
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}</> is defined, but not
|
||||
For functions, <literal>db_procedure:{execute}</> is defined, but is not
|
||||
checked in this version.
|
||||
</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
|
||||
<productname>sepgsql</> is enabled.
|
||||
<filename>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
|
||||
When <xref linkend="sql-security-label"> is executed, <literal>setattr</>
|
||||
and <literal>relabelfrom</> will be checked on the object being relabeled
|
||||
with its old security label, then <literal>relabelto</> with the supplied
|
||||
new security label.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the case where multiple label providers are installed and the user tries
|
||||
to set a security label, but is not managed by <productname>SELinux</>,
|
||||
to set a security label, but it is not managed by <productname>SELinux</>,
|
||||
only <literal>setattr</> should be checked here.
|
||||
This is currently not checked due to implementation restrictions.
|
||||
This is currently not done due to implementation restrictions.
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Trusted Procedure</title>
|
||||
<title>Trusted Procedures</title>
|
||||
<para>
|
||||
Trusted procedures are similar to security definer functions or set-uid
|
||||
commands. <productname>SELinux</> provides a feature to allow trusted
|
||||
@ -453,9 +485,9 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
|
||||
|
||||
<para>
|
||||
In this case, a regular user cannot reference <literal>customer.credit</>
|
||||
directly, but a trusted procedure <literal>show_credit</> enables us
|
||||
to print the credit card number of customers with some of the digits masked
|
||||
out.
|
||||
directly, but a trusted procedure <literal>show_credit</> allows him
|
||||
to print the credit card numbers of customers with some of the digits
|
||||
masked out.
|
||||
</para>
|
||||
</sect3>
|
||||
|
||||
@ -473,16 +505,6 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
|
||||
<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>
|
||||
@ -506,7 +528,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
|
||||
<listitem>
|
||||
<para>
|
||||
<productname>PostgreSQL</> does not support row-level access; therefore,
|
||||
<productname>sepgsql</productname> does not support it either.
|
||||
<filename>sepgsql</filename> does not support it either.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -515,11 +537,11 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
|
||||
<term>Covert channels</term>
|
||||
<listitem>
|
||||
<para>
|
||||
<productname>sepgsql</> never tries to hide existence of
|
||||
a certain object, even if the user is not allowed to the reference.
|
||||
<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 reference contents of these objects. The existence
|
||||
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>
|
||||
@ -535,7 +557,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
|
||||
<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,
|
||||
This wiki page provides a brief overview, security design, architecture,
|
||||
administration and upcoming features.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user