diff --git a/contrib/sepgsql/.gitignore b/contrib/sepgsql/.gitignore
index 1e4a297b09..811143c074 100644
--- a/contrib/sepgsql/.gitignore
+++ b/contrib/sepgsql/.gitignore
@@ -1 +1,5 @@
/sepgsql.sql
+/sepgsql-regtest.fc
+/sepgsql-regtest.if
+/sepgsql-regtest.pp
+/tmp
diff --git a/contrib/sepgsql/dml.c b/contrib/sepgsql/dml.c
index cfa436d37d..684b5ee8e6 100644
--- a/contrib/sepgsql/dml.c
+++ b/contrib/sepgsql/dml.c
@@ -171,12 +171,12 @@ check_relation_privileges(Oid relOid,
SEPG_DB_TABLE__DELETE)) != 0)
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("selinux: hardwired security policy violation")));
+ errmsg("SELinux: hardwired security policy violation")));
if (relkind == RELKIND_TOASTVALUE)
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("selinux: hardwired security policy violation")));
+ errmsg("SELinux: hardwired security policy violation")));
}
/*
diff --git a/contrib/sepgsql/hooks.c b/contrib/sepgsql/hooks.c
index 6b55e484cf..bc7ce51cf1 100644
--- a/contrib/sepgsql/hooks.c
+++ b/contrib/sepgsql/hooks.c
@@ -91,7 +91,7 @@ sepgsql_client_auth(Port *port, int status)
if (getpeercon_raw(port->sock, &context) < 0)
ereport(FATAL,
(errcode(ERRCODE_INTERNAL_ERROR),
- errmsg("selinux: failed to get the peer label")));
+ errmsg("SELinux: unable to get peer label")));
sepgsql_set_client_label(context);
@@ -318,7 +318,7 @@ sepgsql_utility_command(Node *parsetree,
{
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("SELinux: LOAD is not allowed anyway.")));
+ errmsg("SELinux: LOAD is not permitted")));
}
break;
default:
@@ -352,8 +352,8 @@ _PG_init(void)
*/
if (IsUnderPostmaster)
ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("Not allowed to load SE-PostgreSQL now")));
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("sepgsql must be loaded via shared_preload_libraries")));
/*
* Check availability of SELinux on the platform.
@@ -414,7 +414,7 @@ _PG_init(void)
if (getcon_raw(&context) < 0)
ereport(ERROR,
(errcode(ERRCODE_INTERNAL_ERROR),
- errmsg("selinux: unable to get security label of server")));
+ errmsg("SELinux: failed to get server security label")));
sepgsql_set_client_label(context);
/* Security label provider hook */
diff --git a/contrib/sepgsql/label.c b/contrib/sepgsql/label.c
index bc28adfea5..ad568f8aa6 100644
--- a/contrib/sepgsql/label.c
+++ b/contrib/sepgsql/label.c
@@ -81,7 +81,7 @@ sepgsql_get_label(Oid classId, Oid objectId, int32 subId)
if (security_get_initial_context_raw("unlabeled", &unlabeled) < 0)
ereport(ERROR,
(errcode(ERRCODE_INTERNAL_ERROR),
- errmsg("selinux: unable to get initial security label")));
+ errmsg("SELinux: failed to get initial security label")));
PG_TRY();
{
label = pstrdup(unlabeled);
@@ -114,7 +114,7 @@ sepgsql_object_relabel(const ObjectAddress *object, const char *seclabel)
security_check_context_raw((security_context_t) seclabel) < 0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_NAME),
- errmsg("invalid security label: \"%s\"", seclabel)));
+ errmsg("SELinux: invalid security label: \"%s\"", seclabel)));
/*
* Do actual permission checks for each object classes
*/
@@ -154,13 +154,11 @@ sepgsql_getcon(PG_FUNCTION_ARGS)
char *client_label;
if (!sepgsql_is_enabled())
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("SELinux: now disabled")));
+ PG_RETURN_NULL();
client_label = sepgsql_get_client_label();
- PG_RETURN_POINTER(cstring_to_text(client_label));
+ PG_RETURN_TEXT_P(cstring_to_text(client_label));
}
/*
@@ -179,14 +177,14 @@ sepgsql_mcstrans_in(PG_FUNCTION_ARGS)
if (!sepgsql_is_enabled())
ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("SELinux: now disabled")));
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("sepgsql is not enabled")));
if (selinux_trans_to_raw_context(text_to_cstring(label),
&raw_label) < 0)
ereport(ERROR,
(errcode(ERRCODE_INTERNAL_ERROR),
- errmsg("SELinux: internal error on mcstrans")));
+ errmsg("SELinux: could not translate security label")));
PG_TRY();
{
@@ -200,7 +198,7 @@ sepgsql_mcstrans_in(PG_FUNCTION_ARGS)
PG_END_TRY();
freecon(raw_label);
- PG_RETURN_POINTER(cstring_to_text(result));
+ PG_RETURN_TEXT_P(cstring_to_text(result));
}
/*
@@ -219,14 +217,14 @@ sepgsql_mcstrans_out(PG_FUNCTION_ARGS)
if (!sepgsql_is_enabled())
ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("SELinux: now disabled")));
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("sepgsql is not currently enabled")));
if (selinux_raw_to_trans_context(text_to_cstring(label),
&qual_label) < 0)
ereport(ERROR,
(errcode(ERRCODE_INTERNAL_ERROR),
- errmsg("SELinux: internal error on mcstrans")));
+ errmsg("SELinux: could not translate security label")));
PG_TRY();
{
@@ -240,7 +238,7 @@ sepgsql_mcstrans_out(PG_FUNCTION_ARGS)
PG_END_TRY();
freecon(qual_label);
- PG_RETURN_POINTER(cstring_to_text(result));
+ PG_RETURN_TEXT_P(cstring_to_text(result));
}
/*
@@ -360,8 +358,7 @@ exec_object_restorecon(struct selabel_handle *sehnd, Oid catalogId)
break;
default:
- elog(ERROR, "Bug? %u is not supported to set initial labels",
- catalogId);
+ elog(ERROR, "unexpected catalog id: %u", catalogId);
break;
}
@@ -387,12 +384,12 @@ exec_object_restorecon(struct selabel_handle *sehnd, Oid catalogId)
}
else if (errno == ENOENT)
ereport(WARNING,
- (errmsg("no valid initial label on %s (type=%d), skipped",
+ (errmsg("SELinux: no initial label assigned for %s (type=%d), skipping",
objname, objtype)));
else
ereport(ERROR,
(errcode(ERRCODE_INTERNAL_ERROR),
- errmsg("libselinux: internal error")));
+ errmsg("SELinux: could not determine initial security label for %s (type=%d)", objname, objtype)));
}
systable_endscan(sscan);
@@ -422,8 +419,8 @@ sepgsql_restorecon(PG_FUNCTION_ARGS)
*/
if (!sepgsql_is_enabled())
ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("SELinux: now disabled")));
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("sepgsql is not currently enabled")));
/*
* Check DAC permission. Only superuser can set up initial
* security labels, like root-user in filesystems
@@ -431,7 +428,7 @@ sepgsql_restorecon(PG_FUNCTION_ARGS)
if (!superuser())
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("must be superuser to restore initial contexts")));
+ errmsg("SELinux: must be superuser to restore initial contexts")));
/*
* Open selabel_lookup(3) stuff. It provides a set of mapping
@@ -452,7 +449,7 @@ sepgsql_restorecon(PG_FUNCTION_ARGS)
if (!sehnd)
ereport(ERROR,
(errcode(ERRCODE_INTERNAL_ERROR),
- errmsg("SELinux internal error")));
+ errmsg("SELinux: failed to initialize labeling handle")));
PG_TRY();
{
/*
diff --git a/doc/src/sgml/sepgsql.sgml b/doc/src/sgml/sepgsql.sgml
index 91b8614b81..d95d121f4b 100644
--- a/doc/src/sgml/sepgsql.sgml
+++ b/doc/src/sgml/sepgsql.sgml
@@ -8,9 +8,12 @@
- The sepgsql> is a module which performs as an external
- security provider; to support label based mandatory access control
- (MAC) base on SELinux> policy.
+ sepgsql> is a loadable module which supports label-based
+ mandatory access control (MAC) based on SELinux> security
+ policy. This implementation is not complete, and primarily provides
+ protection for Data Manipulation Language statements (DML). Support for
+ fine-grained access control of Data Definition Language (DDL) and Data
+ Control Language (DCL) statements may be added in a future release.
This extension won't build at all unless the installation was configured
@@ -21,59 +24,44 @@
Overview
- PostgreSQL> provides various kind of hooks. Some of these
- hooks can be utilized to make access control decision on the supplied
- users' accesses on database objects.
- We call plug-in modules making access control decision based on its own
- security model as an external security provider.
+ This module integrates with SELinux> to provide an
+ additional layer of security checking above and beyond what is normaly
+ provided by PostgreSQL. From the perspective of
+ 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
+ PostgreSQL.
+
- This module acquires control on these strategic points, then it asks
- SELinux> to check whether the supplied access shall be
- allowed, or not. Then, it returns its access control decision.
- If violated, this module prevents this access with rising an error for
- example.
+ SELinux access control decisions are made using
+ security labels, which are represented by strings such as
+ system_u:object_r:sepgsql_table_t:s0>. Each access control
+ decision involves two labels: the label of the subject attempting to
+ perform the action, and the label of the object on which the operation is
+ to be performed. Since these labels can be applied to any sort of object,
+ access control decisions for objects stored within the database can be
+ (and, with this module, are) subjected to the same general criteria used
+ for objects of any other type (e.g. 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.
+
- A series of making decision is done independently from the default
- database privilege mechanism. Users must be allowed with both of access
- control models, whenever they try to access something.
-
-
- We can see SELinux> as a function which takes two arguments
- then returns a bool value; allowed or denied. The first argument in this
- analogy is label of subject which tries to reference a certain obejct.
- The other one is label of the object being referenced in this operation.
-
-
- Label is a formatted string,
- like system_u:object_r:sepgsql_table_t:s0>.
- It is not a property depending on characteristics of a certain kind of
- object, so we can apply common credentials on either database objects
- or others.
-
-
- PostgreSQL> 9.1 or later supports
- statement that allows to assign
- a security label on specified database objects, if user wants to change
- label from the creation default.
- Also SELinux> provides an interface to obtain security
- label of the peer process that connected to.
-
-
- These facilities enable to integrate SELinux> model within
- access controls to database objects. Because it makes access control
- decision according to a common centralized security policy (a set of rules),
- its decision will be always consistent independent from the way to store
- information assets.
+ The statement allows assignment of
+ a security label to a database object.
+
Installation
+
- The sepgsql> module requires the following packages to install.
- Please check it at first.
+ This module has several prerequisites.
+
Linux kernel
@@ -103,14 +91,14 @@
The default security policy provides a set of access control rules.
- Some of distribution may backports necessary rules, even if base
- policy was older than above version.
+ Some distributions may backport necessary rules to older policy versions.
- SE-PostgreSQL> needs SELinux> being
+
+ sepgsql> needs SELinux> being
available on the platform. You can check the current setting using
sestatus>.
@@ -122,38 +110,41 @@ Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
- If disabled or not-installed, you need to set up SELinux>
- prior to all the installation step of SE-PostgreSQL>.
+ If SELinux> is disabled or not installed, you must set
+ that product up first before installing this module.
+
- On the compile time, add --with-selinux> option to
- the configure> script to check existence of
- the libselinux>, and to set a flag whether
- we build this contrib module, or not.
+ At compile time, pass the --with-selinux> option to
+ the configure> script to enable this module.
+
$ ./configure --enable-debug --enable-cassert --with-selinux
$ make
$ make install
-
- Next to the initdb>, add '$libdir/sepgsql'>
- to in
- the postgresql.conf>.
- It enables to load sepgsql> on the starting up of
- postmaster process.
-
- Then, load the sepgsql.sql script for each databases.
- It installs functions corresponding to security label management, and
- tries to assign initial labels on the target objects.
+ Following initdb>, add '$libdir/sepgsql'>
+ to in
+ the postgresql.conf>. Note that sepgsql>
+ must be loaded at server startup.
+
+
+ Next, load the sepgsql.sql script for each database.
+ It installs functions for security label management, and attempts to assign
+ initial labels to the target objects.
+
+
The following instruction assumes your installation is under the
/usr/local/pgsql> directory, and the database cluster is in
- /usr/local/pgsql/data>. Substitute your paths appropriately.
+ /usr/local/pgsql/data>. Adjust the paths shown below as
+ appropriate for your installaton.
+
$ initdb -D $PGDATA
$ vi $PGDATA/postgresql.conf
@@ -162,34 +153,32 @@ $ for DBNAME in template0 template1 postgres; do
< /usr/local/pgsql/share/contrib/sepgsql.sql > /dev/null
done
+
- If all the installation process was done with no errors, start postmaster
- process. SE-PostgreSQL> shall prevent violated accesses
- according to the security policy of SELinux>.
+ If the installation process completes without error, you can now start the
+ server normally.
Regression Tests
- The regression test of this module requires a few more configurations
- on the platform system, in addition to the above installation process.
- See the following steps.
+ Due to the nature of SELinux, running the
+ regression tests for this module requires several additional configuration
+ steps.
+
- First, install the policy package for regression test.
+ First, install the policy package for the regression test.
The sepgsql-regtest.pp> is a special purpose policy package
- that provides a set of rules to be allowed during the regression test
- cases. It shall be installed at /usr/local/pgsql/share/contrib>
- directory in the default setup.
-
-
- You need to install this policy package using semodule>
- command which enables to link supplied policy packages and load them
- into the kernel space. If you could install the pakage correctly,
- semodule> -l> prints sepgsql-regtest as a part
- of policy packages currently available.
+ which provides a set of rules to be allowed during the regression tests.
+ You need to install this policy package using the semodule>
+ command, which links supplied policy packages and loads them
+ into the kernel space. If this packages is correctly installed,
+ semodule> -l> should list sepgsql-regtest as an
+ available policy package.
+
$ su
# semodule -u /usr/local/pgsql/share/contrib/sepgsql-regtest.pp
@@ -198,78 +187,50 @@ $ su
sepgsql-regtest 1.03
:
+
- Second, turn on the sepgsql_regression_test_mode>.
+ Second, turn on sepgsql_regression_test_mode>.
We don't enable all the rules in the sepgsql-regtest.pp>
- in the default, for your system's safety.
+ 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.
+
$ su
# 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.
-
- This test policy is designed to kick each test cases from the
- unconfined_t> domain that is a default choice in most of
- the known SELinux> installation base.
- So, you don't need to set up anything special, as long as you didn't
- change default configuration of SELinux before.
-
+
The id> command tells us the current working domain.
- Confirm your shell is now performing with unconfined_t>
+ Confirm your shell is now performing with the unconfined_t>
domain as follows.
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-
- If not an expected one, you should revert this configuration.
- The section will give you
- some useful hints.
-
-
- Then, you will see the all-green result of regression test,
- if we have no problem here.
-
-
-$ make -C contrib/sepgsql/ installcheck
- :
-../../src/test/regress/pg_regress --inputdir=. --psqldir=/usr/local/pgsql/bin \
- --dbname=contrib_regression --launcher ../../contrib/sepgsql/launcher \
- label dml
-(using postmaster on Unix socket, default port)
-============== dropping database "contrib_regression" ==============
-DROP DATABASE
-============== creating database "contrib_regression" ==============
-CREATE DATABASE
-ALTER DATABASE
-============== running regression test queries ==============
-test label ... ok
-test dml ... ok
-test misc ... ok
-=====================
- All 3 tests passed.
-=====================
-
- If pg_regress> failed to launch psql> command,
- here is a hint to fix up the matter.
-
- When we try to launch psql> command with restrictive
- privileges, the psql> must eb labeled as bin_t>.
- If not, try to run restorecon> to fix up security label of
- the commands as expected.
+ See for details on adjusting your
+ working domain, if necessary.
+
+
+ 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.
+
+
$ restorecon -R /usr/local/pgsql/
@@ -286,28 +247,20 @@ $ restorecon -R /usr/local/pgsql/
- This parameter enables to perform SE-PostgreSQL>
- in permissive mode independent from the system setting.
- The default is off (according to the system setting).
+ This parameter enables SE-PostgreSQL> to function
+ in permissive mode, regardless of the system setting.
+ The default is off.
This parameter can only be set in the postgresql.conf>
file or on the server command line.
+
- We have two performing mode except for disabled; The one is enforcing
- mode that checks the security policy on references and actually prevents
- violated accesses. The other is permissive mode that only checks
- the security policy, but does not prevents anything except for log
- generation.
- This log shall be utilized for debugging of the security policy itself.
-
-
- When this parameter is on, SE-PostgreSQL> performs
- in permissive mode, even if the platform system is working on enforcing
- mode.
- We recommend users to keep the default setting, except for the case
- when we develop security policy by ourself.
+ When this parameter is on, SE-PostgreSQL> functions
+ in permissive mode, even if the platform system is working in enforcing
+ mode. This parameter is primarily useful for testing purposes.
+
sepgsql.debug_audit> (boolean>)>
@@ -316,21 +269,21 @@ $ restorecon -R /usr/local/pgsql/
- This parameter enables to print audit messages independent from
+ This parameter enables the printing of audit messages independent from
the policy setting.
The default is off (according to the security policy setting).
+
The security policy of SELinux> also has rules to
- control what accesses shall be logged, or not.
- In the default, any access violations are logged, but any allowed
- accesses are not logged.
+ control whether or not particular accesses are logged.
+ By default, access violations are logged, but allowed
+ accesses are not.
+
- When this parameter is on, all the possible logs shall be printed
- independently from the policy settings.
- We recommend to keep the variable turned off in normal cases to
- avoid noisy messages.
+ This parameter forces all possible logging to be turned on, regardless
+ of the system policy.
@@ -344,48 +297,35 @@ $ restorecon -R /usr/local/pgsql/
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.
- And, these entities are identified by a security label.
+ it is a client of database) and an object entity, 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>.
+
- We call a set of these rules as security policy.
- All the access control decision shall be made according to the security
- policy, when we ask SELinux whether the required action shall be allowed
- or not.
- Thus, we have no way to control accesses on any sort of objects without
- security labels.
- (SELinux> assumes unlabeled_t> is assigned,
- if no valid security label is assigned on the target object.)
+ Currently, sepgsql allows security labels to be
+ assigned to schemas, tables, columns, sequences, views, and functions.
+ When sepgsql is in use, security labels are
+ automatically assigned to suppoted database objects at creation time.
+ This label is called as a default security label, being 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.
+
- This version of SE-PostgreSQL> supports to assign
- a security label on these database object classes: schema, table, column,
- sequence, view and procedure.
- Other database object classes are not supported to assign security label
- on, right now.
-
-
- A security label shall be automatically assigned to the supported
- database objects on their creation time.
- This label is called as a default security label; being decided according
- to the security policy, or a pair of security label of the client and
- upper object for more correctly.
-
-
- A new database object basically inherits security label of the upper
- object. A new column inherits security label of its parent table for
- instance.
- If and when the security policy has special rules called as
- type-transition on a pair of the client and upper object, we can assign
- an individual label as a default. The upper object depends on sort of
- object classes as follows.
+ A new database object basically inherits 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.
+ The meaning of the term "parent object" varies by object class, as follows.
+
schema
- Its upper object is the current database.
+ The parent object is the current database.
@@ -393,7 +333,7 @@ $ restorecon -R /usr/local/pgsql/
table
- Its upper object is the schema object which owns the new table.
+ The parent object is the containing schema.
@@ -401,7 +341,7 @@ $ restorecon -R /usr/local/pgsql/
column
- Its upper object is the table object which owns the new column.
+ The parent object is the table.
@@ -409,7 +349,7 @@ $ restorecon -R /usr/local/pgsql/
sequence
- Its upper object is the schema object which owns the new sequence.
+ The parent object is the containing schema.
@@ -417,15 +357,15 @@ $ restorecon -R /usr/local/pgsql/
view
- Its upper object is the schema object which owns the new view.
+ The parent object is the containing schema.
- procedure
+ function
- Its upper object is the schema object which owns the new procedure.
+ Its parent object is the containing schema.
@@ -433,56 +373,62 @@ $ restorecon -R /usr/local/pgsql/
DML Permissions
+
This section introduces what permissions shall be checked on DML;
SELECT>, INSERT>, UPDATE> and
DELETE>.
+
DML statements are used to reference or modify contents within
the specified database objects; such as tables or columns.
- We basically checks access rights of the client on all the appeared
- objects in the given statement, and kind of privileges depend on
- class of object and sort of accesses.
+ We basically checks access rights of the client on all the objects
+ mentioned in the given statement, and the kind of privileges checked
+ depend on the class of the object and the type of access.
+
For tables, db_table:select>, db_table:insert>,
- db_table:update> or db_table:delete> shall be
+ db_table:update> or db_table:delete> is
checked for all the appeared target tables depending on the sort of
statement;
- In addition, db_table:select> shall be also checked for
+ in addition, db_table:select> is also checked for
all the tables that containin the columns to be referenced in
WHERE> or RETURNING> clause, as a data source
of UPDATE>, and so on.
+
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
+
In this case, we must have db_table:select>, not only
db_table:update>, because t1.a> is referenced
- within WHERE> clause.
- Also note that column-level permission shall be checked individually.
+ within WHERE> clause. Column-level permissions will be
+ checked as well, for each referenced column.
+
The client must be allowed to reference all the appeared tables and
- columns, even if they are originated from views then expanded, unlike
- the default database privileges, because we intend to apply consistent
- access control rules independent from the route to reference contents
- of the tables.
+ columns, even if they are originated from views then expanded, because we
+ intend to apply consistent access control rules independent from the
+ manner in which the table contents are referenced.
+
- For columns, db_column:select> shall be also checked on
+ For columns, db_column:select> is checked on
not only the columns being read using SELECT>, but being
referenced in other DML statement.
+
Of course, it also checks db_column:update> or
db_column:insert> on the column being modified by
UPDATE> or INSERT>.
- Note that we have no definition of column-level delete permission,
- like as the default database privilege doing.
+
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
@@ -495,31 +441,35 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
Also note that db_table:{select update}> shall be checked
in the table-level granularity.
+
For sequences, db_sequence:get_value> when we reference
- a sequence object using SELECT>, however, note that we
+ a sequence object using SELECT>; however, note that we
cannot check permissions on execution of corresponding functions
such as lastval()> right now, although they performs same
job, because here is no object access hook to acquire controls.
+
For views, db_view:expand> shall be checked, then any other
corresponding permissions shall be also checked on the objects being
expanded from the view, individually.
- Note that both of permissions have to be allowed.
+
- For procedures, db_procedure:{execute}> is defined, but not
+ For functions, db_procedure:{execute}> is defined, but not
checked in this version.
+
Here is a few more corner cases.
The default database privilege system allows database superusers to
modify system catalogs using DML commands, and reference or modify
- toast tables, however, both of the cases shall be denied when
- SE-PostgreSQL> is enabled.
+ toast tables. These operations are prohibited when
+ sepgsql> is enabled.
+
DDL Permissions
@@ -528,17 +478,15 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
with an old security label, then relabelto> on the supplied
new security label.
+
In a case when multiple label providers are installed and user tries
to set a security label, but is not managed by SELinux>,
only setattr> should be checked here.
- However, it is not unavailable because of limitation of the hook.
-
-
- As we will describe in section,
- SE-PostgreSQL> does not control any other DDL operations.
+ This is currently not done due to implementation restrictions.
+
Trusted Procedure
@@ -548,6 +496,7 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
for more correctness) during execution of certain functions; being
called as trusted procedures.
+
A trusted function is a function with a special security label being
set up as a trusted procedure.
@@ -556,6 +505,7 @@ UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
The default security policy also provides this special security label.
See the following example.
+
postgres=# CREATE TABLE customer (
cid int primary key,
@@ -575,9 +525,11 @@ postgres=# SECURITY LABEL ON FUNCTION show_credit(int)
IS 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0';
SECURITY LABEL
+
Above operations shall be done by administrative users.
+
postgres=# SELECT * FROM customer;
ERROR: SELinux: security policy violation
@@ -588,71 +540,71 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
2 | hanako | 5555-6666-7777-xxxx
(2 rows)
+
In this case, a regular user cannot reference customer.credit>
directly, but a trusted procedure show_credit> enables us
to print credit number of customers with a bit modification.
+
Miscellaneous
In this version, we reject command across
- the board, because the binary module can override security hooks to
- make access control decision. It means a risk to invalidate all the
- control by security providers.
+ the board, because any module loaded could easily circumvent security
+ policy enforcement.
+
Limitations
-
- This section introduces limitations of SE-PostgreSQL>
- in this version.
-
+
Userspace access vector cache
- SE-PostgreSQL> tells SELinux> its access
- control decision. It takes system call invocation being heavy, however,
- we can reduce number of the invocations using caching mechanism; called
- as access vector cache in SELinux>.
- Because of code size, SE-PostgreSQL> does not support
- this mechanism yet.
+ sepgsql> does not yet support an access vector cache.
+ This would likely improve performance.
+
- DDL Permissions
+ Data Definition Language (DDL) Permissions
- Now PostgreSQL> does not provide a set of hooks on
- the DDL routines.
- It means plugin modules cannot acquire control here,
- so SE-PostgreSQL> does not check DDL Permissions
- right now.
+ Due to implementation restrictions, DDL permissions are not checked.
+
+
+ Data Control Language (DCL) Permissions
+
+
+ Due to implementation restrictions, DCL permissions are not checked.
+
+
+
+
Row-level access control
- Now SE-PostgreSQL> does not support row-level access
- control, because a few needed facilities are not supported yet.
- The one is security labels on users' tables. The other is behavior of
- optimizer. Also see for more details.
- We know similar issue on VIEW.
+ PostgreSQL> does not support row-level access; therefore,
+ sepgsql does not support it either.
+
Covert channels
- SE-PostgreSQL> never tries to hide existence of
+ sepgsql> never tries to hide existence of
a certain object, even if user is not allowed to reference.
For example, we can infer an existence of invisible object using
primary-key confliction, foreign-key violation, and so on, even if
@@ -662,6 +614,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
+
External Resources
@@ -669,7 +622,7 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
SE-PostgreSQL Introduction
- This wikipage provides a brief-overview, security design, architecture,
+ This wiki page provides a brief-overview, security design, architecture,
administration and upcoming feature for more details.
@@ -678,9 +631,9 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
Fedora SELinux User Guide
- This document provides wide spectrum of knowledge to administrate
- SELinux on your systems.
- It primary focuses on Fedora, but not limited to Fedora.
+ This document provides wide spectrum of knowledge to administer
+ SELinux> on your systems.
+ It primary focuses on Fedora, but is not limited to Fedora.
@@ -688,13 +641,15 @@ postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
Fedora SELinux FAQ
- This document provides FAQs about SELinux.
- It primary focuses on Fedora, but not limited to Fedora.
+ This document answers frequently asked questins about
+ SELinux.
+ It primary focuses on Fedora, but is not limited to Fedora.
+
Author