From: Tom Lane Date: Wed, 28 Sep 2011 00:15:54 +0000 (-0400) Subject: Take sepgsql regression tests out of the regular regression test mechanism. X-Git-Tag: REL9_1_2~94 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=39be6957725bf4b9764a10cf368cc6ec8e21dec6;p=postgresql 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. --- diff --git a/contrib/sepgsql/Makefile b/contrib/sepgsql/Makefile index 7fee218db9..c3ed2f5c1e 100644 --- a/contrib/sepgsql/Makefile +++ b/contrib/sepgsql/Makefile @@ -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 diff --git a/contrib/sepgsql/test_sepgsql b/contrib/sepgsql/test_sepgsql new file mode 100755 index 0000000000..9b7262ae82 --- /dev/null +++ b/contrib/sepgsql/test_sepgsql @@ -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" diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml index fc379885d8..e9b9770b42 100644 --- a/doc/src/sgml/sepgsql.sgml +++ b/doc/src/sgml/sepgsql.sgml @@ -8,15 +8,15 @@ - sepgsql is a loadable module which supports label-based + sepgsql is a loadable module that supports label-based mandatory access control (MAC) based on SELinux security policy. - 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 . @@ -31,8 +31,8 @@ SELinux, this module allows PostgreSQL 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 PostgreSQL. @@ -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. @@ -60,18 +60,18 @@ Installation - This module can only be used on Linux 2.6.28 - or higher with SELinux enabled. It is not - available on any other platform, and must be explicitly enabled using - --with-selinux. You will also need libselinux - 2.0.93 or higher and selinux-policy 3.9.13 or higher - (some distributions may backport the necessary rules into older policy + sepgsql can only be used on Linux + 2.6.28 or higher with SELinux enabled. + It is not available on any other platform. You will also need + libselinux 2.0.93 or higher and + selinux-policy 3.9.13 or higher (although some + distributions may backport the necessary rules into older policy versions). The sestatus command allows you to check the status of - SELinux. + SELinux. A typical display is: $ sestatus SELinux status: enabled @@ -86,112 +86,128 @@ Policy from config file: targeted - To use this module, you must add include sepgsql - in . The module will not - function if loaded in any other manner. Once the module is loaded, you + To build this module, include the option --with-selinux in + your PostgreSQL configure command. Be sure that the + libselinux-devel RPM is installed at build time. + + + + To use this module, you must include sepgsql + in the parameter in + postgresql.conf. The module will not function correctly + if loaded in any other manner. Once the module is loaded, you should execute sepgsql.sql in each database. This will install functions needed for security label management, and assign initial security labels. - The following instructions that assume your installation is under the - /usr/local/pgsql directory and the database cluster is - under the /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 sepgsql functions and security labels installed. + Adjust the paths shown as appropriate for your installation: -$ 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 - If the installation process completes without error, you can now start the - server normally. - - - - Please note that you may see the following notifications depending on - the combination of a particular version of libselinux - and selinux-policy. + Please note that you may see some or all of the following notifications + depending on the particular versions you have of + libselinux and selinux-policy: /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 - This message is harmless and may be safely ignored. + These messages are harmless and should be ignored. + + + + If the installation process completes without error, you can now start the + server normally. Regression Tests + Due to the nature of SELinux, running the - regression tests for this module requires several additional configuration - steps. + regression tests for sepgsql requires several extra + configuration steps, some of which must be done as root. + The regression tests will not be run by an ordinary + make check or make installcheck command; you must + set up the configuration and then invoke the test script manually. + The tests must be run in the 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 make installcheck not + make check. - First, set up sepgsql according to - the . 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 sepgsql in a working database + according to the instructions in . + Note that the current operating system user must be able to connect to the + database as superuser without password authentication. Second, build and install the policy package for the regression test. - The sepgsql-regtest.pp is a special purpose policy package + The 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 - (sepgsql-regtest.te), which is normally done using - make. You will need to locate the appropriate + sepgsql-regtest.te, which is done using + make 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 - 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 + semodule command, which loads supplied policy packages + into the kernel. If the package is correctly installed, semodule -l should list sepgsql-regtest as an - available policy package. + available policy package: -$ 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 - : Third, turn on sepgsql_regression_test_mode. - We don't enable all the rules in the sepgsql-regtest.pp + We don't enable all the rules in sepgsql-regtest by default, for your system's safety. - The sepgsql_regression_test_mode parameter is associated - with rules to launch regression test. - It can be turned on using setsebool command. + The sepgsql_regression_test_mode parameter enables + the rules needed to launch the regression tests. + It can be turned on using the setsebool command: -$ 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 - Last, kick the regression test from the unconfined_t domain. - - - - The id command tells us the current working domain. - Confirm your shell is now performing with the unconfined_t - domain as follows. + Fourth, verify your shell is operating in the unconfined_t + domain: $ id -Z @@ -204,15 +220,34 @@ unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 - If pg_regress fails to launch the psql command, - you may need to ensure that the psql command is labeled - as bin_t. If it is not, the restorecon command can - often be used to fix up security labels within the - PostgreSQL installation directory. + Finally, run the regression test script: + + +$ ./test_sepgsql + + + + 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 + sepgsql module. + + + + After completing the tests, it's recommended you disable + the sepgsql_regression_test_mode parameter: -$ restorecon -R /usr/local/pgsql/ +$ sudo setsebool sepgsql_regression_test_mode off + + + + You might prefer to remove the sepgsql-regtest policy + entirely: + + + +$ sudo semodule -r sepgsql-regtest @@ -227,7 +262,7 @@ $ restorecon -R /usr/local/pgsql/ - This parameter enables SE-PostgreSQL to function + This parameter enables sepgsql to function in permissive mode, regardless of the system setting. The default is off. This parameter can only be set in the postgresql.conf @@ -235,8 +270,8 @@ $ restorecon -R /usr/local/pgsql/ - When this parameter is on, SE-PostgreSQL functions - in permissive mode, even if the platform system is working in enforcing + When this parameter is on, sepgsql functions + in permissive mode, even if SELinux in general is working in enforcing mode. This parameter is primarily useful for testing purposes. @@ -249,9 +284,10 @@ $ restorecon -R /usr/local/pgsql/ - 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. @@ -276,19 +312,20 @@ $ restorecon -R /usr/local/pgsql/ Controlled Object Classes The security model of 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 unlabeled_t. - Currently, sepgsql allows security labels to be + Currently, sepgsql allows security labels to be assigned to schemas, tables, columns, sequences, views, and functions. - When sepgsql is in use, security labels are + When sepgsql 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. @@ -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. @@ -309,41 +346,29 @@ $ restorecon -R /usr/local/pgsql/ For tables, db_table:select, db_table:insert, db_table:update or 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, db_table:select is also checked for all the tables that contain the columns referenced in the WHERE or RETURNING clause, as a data source - of UPDATE, and so on. - + of UPDATE, and so on. For example, consider: - UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; - In this case, we must have db_table:select in addition to + In this case we must have db_table:select in addition to db_table:update, because t1.a is referenced within the WHERE clause. Column-level permissions will also be checked for each referenced column. - - 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. - - For columns, db_column:select is checked on - not only the columns being read using SELECT, but being + not only the columns being read using SELECT, but those being referenced in other DML statements. - - - Of course, it also checks db_column:update or - db_column:insert on the column being modified by + db_column:insert on columns being modified by UPDATE or INSERT. @@ -351,11 +376,11 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; - In this case, it checks db_column:update on - the t1.x being updated, db_column:{select update} - on the t1.y being updated and referenced, - and db_column:select on the t1.z being only - referenced in the WHERE clause. + In this case, it checks db_column:update on the column + t1.x being updated, db_column:{select update} + on the column t1.y being updated and referenced, and + db_column:select on the column t1.z, since that is + only referenced in the WHERE clause. db_table:{select update} will also be checked at the table level. @@ -368,43 +393,50 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100; - For views, db_view:expand shall be checked, then any other - corresponding permissions shall be also checked on the objects being + For views, db_view:expand will be checked, then any other + required permissions will be checked on the objects being expanded from the view, individually. - For functions, db_procedure:{execute} is defined, but not + For functions, db_procedure:{execute} is defined, but is not checked in this version. + + 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. + + 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 - sepgsql is enabled. + sepgsql is enabled. DDL Permissions - On command, setattr and - relabelfrom shall be checked on the object being relabeled - with an old security label, then relabelto on the supplied + When is executed, setattr + and relabelfrom will be checked on the object being relabeled + with its old security label, then relabelto with the supplied new security label. In the case where multiple label providers are installed and the user tries - to set a security label, but is not managed by SELinux, + to set a security label, but it is not managed by SELinux, only setattr should be checked here. - This is currently not checked due to implementation restrictions. + This is currently not done due to implementation restrictions. - Trusted Procedure + Trusted Procedures Trusted procedures are similar to security definer functions or set-uid commands. SELinux provides a feature to allow trusted @@ -453,9 +485,9 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; In this case, a regular user cannot reference customer.credit - directly, but a trusted procedure show_credit enables us - to print the credit card number of customers with some of the digits masked - out. + directly, but a trusted procedure show_credit allows him + to print the credit card numbers of customers with some of the digits + masked out. @@ -473,16 +505,6 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; Limitations - - Userspace access vector cache - - - sepgsql does not yet support an access vector cache. - This would likely improve performance. - - - - Data Definition Language (DDL) Permissions @@ -506,7 +528,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; PostgreSQL does not support row-level access; therefore, - sepgsql does not support it either. + sepgsql does not support it either. @@ -515,11 +537,11 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; Covert channels - sepgsql never tries to hide existence of - a certain object, even if the user is not allowed to the reference. + 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. @@ -535,7 +557,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer; SE-PostgreSQL Introduction - This wiki page provides a brief-overview, security design, architecture, + This wiki page provides a brief overview, security design, architecture, administration and upcoming features.