- 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
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 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.
-
- 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.
+ 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 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.
+
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.
+
- 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.
+
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.
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'
+ Following initdb, add '$libdir/sepgsql'
to in
- the postgresql.conf.
-
- It enables to load sepgsql on the starting up of
- postmaster process.
+ the
postgresql.conf. Note that sepgsql+ must be loaded at server startup.
+
- 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.
+ 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
< /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
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.
+ See for details on adjusting your
+ working domain, if necessary.
+
- Then, you will see the all-green result of regression test,
- if we have no problem here.
+ 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.
-
-$ 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.
-
$ 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)
- 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.
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.
-
- 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.)
-
- 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.
+ 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.
+
- 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.
+ 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.
+
- 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.
table
- Its upper object is the schema object which owns the new table.
+ The parent object is the containing schema.
column
- Its upper object is the table object which owns the new column.
+ The parent object is the table.
sequence
- Its upper object is the schema object which owns the new sequence.
+ The parent object is the containing schema.
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.
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;
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
+
DDL Permissions
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
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.
The default security policy also provides this special security label.
See the following example.
+
postgres=# CREATE TABLE customer (
cid int primary key,
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
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
+
External Resources
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.
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.
- This document provides FAQs about SELinux.
- It primary focuses on Fedora, but not limited to Fedora.
+ This document answers frequently asked questins about
+ It primary focuses on Fedora, but is not limited to Fedora.
+
Author
projects / postgresql.git / commitdiff