mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Take sepgsql regression tests out of the regular regression test mechanism.

Browse Source 
Because these tests require root privileges, not to mention invasive
changes to the security configuration of the host system, it's not
reasonable for them to be invoked by a regular "make check" or "make
installcheck".  Instead, dike out the Makefile's knowledge of the tests,
and change chkselinuxenv (now renamed "test_sepgsql") into a script that
verifies the environment is workable and then runs the tests.  It's
expected that test_sepgsql will only be run manually.

While at it, do some cleanup in the error checking in the script, and
do some wordsmithing in the documentation.
This commit is contained in:
Tom Lane 2011-09-27 20:07:15 -04:00
parent bbd38af3a8
commit cc4ff8742b
4 changed files with 419 additions and 363 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
contrib/sepgsql/Makefile
View File

@ -5,11 +5,9 @@ OBJS = hooks.o selinux.o uavc.o label.o dml.o \
database.o schema.o relation.o proc.o
DATA_built = sepgsql.sql
REGRESS = label dml misc
REGRESS_PREP = check_selinux_environment
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
@ -23,6 +21,3 @@ include $(top_srcdir)/contrib/contrib-global.mk
endif
SHLIB_LINK += -lselinux
check_selinux_environment:
@$(top_builddir)/contrib/sepgsql/chkselinuxenv "$(bindir)" "$(datadir)"

230
contrib/sepgsql/chkselinuxenv
View File

@ -1,230 +0,0 @@
#!/bin/sh
#
# SELinux environment checks to ensure configuration of the operating system
# satisfies prerequisites to run regression test.
# If incorrect settings are found, this script suggest user a hint.
#
PG_BINDIR="$1"
PG_DATADIR="$2"
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 "matchpathcon not found; please install it or update your PATH."
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 "failed"
echo ""
echo "The runcon command must exist and be executable; it is used to"
echo "launch psql command with a particular domain. It is typically"
echo "included within the coreutils 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 "This regression test 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 " \$ su -"
echo " # semanage login -d `whoami`"
echo ""
echo "Or, you can add a setting to log in using the unconfined_t domain:"
echo ""
echo " \$ su -"
echo " # semanage login -a -s unconfined_u -r s0-s0:c0.c255 `whoami`"
echo ""
exit 1
fi
# SELinux must be configured to enforcing mode
echo -n "checking selinux operating mode ... "
CURRENT_MODE=`env LANG=C sestatus | grep 'Current mode:' | awk '{print $3}'`
echo ${CURRENT_MODE:-failed}
if [ "${CURRENT_MODE}" != enforcing ]; then
if [ "${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 command using the 'setenforce' command."
echo
echo " \$ su -"
echo " # setenforce 1"
echo ""
echo "The system default setting is configured in /etc/selinux/config,"
echo "or using a kernel bool parameter."
echo ""
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 ""
fi
exit 1
fi
# 'sepgsql-regtest' policy module must be loaded
echo -n "checking for sepgsql-regtest policy ... "
SELINUX_MNT=`env LANG=C sestatus 2>/dev/null | 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 -C contrib/selinux"
echo " \$ su"
echo " # semodule -i contrib/sepgsql/sepgsql-regtest.pp"
echo ""
echo "To confirm that policy package is installed, use this command:"
echo ""
echo " # 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 " \$ su -"
echo " # setsebool sepgsql_regression_test_mode 1"
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 by test domain
echo -n "checking whether we can run psql ... "
CMD_PSQL="${PG_BINDIR}/psql"
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 sepgsql_regtest_user_t"
echo "domain. The domain has restricted privileges compared to"
echo "unconfined_t, so you should ensure that it is labeled correctly."
echo
echo " \$ su - (not needed, if you owns installation directory)"
EXPECT_PSQL=`matchpathcon -n ${CMD_PSQL} | sed 's/:/ /g' | awk '{print $3}'`
if [ "${EXPECT_PSQL}" = "user_home_t" ]; then
## Case of installation on /home directory
echo " # restorecon -R ${PG_BINDIR}"
echo
echo "Or, using chcon"
echo
echo " # chcon -t user_home_t ${CMD_PSQL}"
else
echo " \$ su - (not needed, if you own the installation directory)"
echo " # restorecon -R ${PG_BINDIR}"
echo
echo "Or, using chcon"
echo
echo " # 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} template1 -tc 'SHOW sepgsql.permissive' 2>/dev/null`"
RETVAL="$?"
if [ $RETVAL -eq 2 ]; then
echo "failed"
echo ""
echo "Unable to connect to the server. Please check your 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 stop and restart the server."
echo ""
exit 1
elif ! echo "$VAL" | grep -q 'off$'; then
echo "failed"
echo ""
echo "The GUC variable '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
echo -n "checking for labels in template1 ... "
NUM=`${CMD_PSQL} template1 -Atc 'SELECT count(*) FROM pg_catalog.pg_seclabel' 2>/dev/null`
if [ -z "${NUM}" ]; then
echo "failed"
echo ""
echo "In order to regression test sepgsql, initial labels must be assigned"
echo "on the 'template1' database. These labels will be copied into the"
echo "regression test database."
echo ""
echo "See Installation section of the PostgreSQL documentation."
echo ""
exit 1
fi
echo "found ${NUM}"
#
# check complete -
#
echo ""
exit 0

264
contrib/sepgsql/test_sepgsql Executable file
View 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"

277
doc/src/sgml/sepgsql.sgml
View File

@ -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.99 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.99 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,40 +86,45 @@ 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 \
&lt; /usr/local/pgsql/share/contrib/sepgsql.sql &gt; /dev/null
postgres --single -F -c exit_on_error=true $DBNAME \
&lt;/usr/local/pgsql/share/contrib/sepgsql.sql &gt;/dev/null
done
</screen>
<para>
If the installation process completes without error, you can now start the
server normally.
</para>
<para>
Please note that you may see some or all of the following notifications
depending on the combination of a particular version of
<productname>libselinux</> and <productname>selinux-policy</>.
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
@ -128,75 +133,81 @@ $ for DBNAME in template0 template1 postgres; do
/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 may be safely ignored.
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 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
@ -209,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>
@ -232,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</>
@ -240,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>
@ -254,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>
@ -281,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>
@ -302,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>
@ -314,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>
@ -356,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>
@ -373,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
@ -458,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>
@ -501,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>
@ -510,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>
@ -530,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>