sepgsql
sepgsql
sepgsql> is a loadable module which 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
.
Overview
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.
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.
The statement allows assignment of
a security label to a database object.
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
versions).
The sestatus> command allows you to check the status of
SELinux.
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
If SELinux> is disabled or not installed, you must set
that product up first before installing this module.
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
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. Adjust the paths shown below as
appropriate for your installaton.
$ initdb
$ vi $PGDATA/postgresql.conf
$ 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
done
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.
First, install the policy package for the regression test.
The sepgsql-regtest.pp> is a special purpose policy package
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
# semodule -l
:
sepgsql-regtest 1.03
:
Second, turn on sepgsql_regression_test_mode>.
We don't enable all the rules in the sepgsql-regtest.pp>
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.
The id> command tells us the current working domain.
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
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/
GUC Parameters
sepgsql.permissive> (boolean)
sepgsql.permissive> configuration parameter
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.
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>)>
sepgsql.debug_audit> configuration parameter>
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 whether or not particular accesses are logged.
By default, access violations are logged, but allowed
accesses are not.
This parameter forces all possible logging to be turned on, regardless
of the system policy.
Features
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
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
assigned to schemas, tables, columns, sequences, views, and functions.
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
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 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.
DML Permissions
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
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.
UPDATE t1 SET x = 2, y = md5sum(y) WHERE z = 100;
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
referenced in other DML statements.
Of course, it also checks db_column:update> or
db_column:insert> on the column being modified by
UPDATE> or INSERT>.
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.
db_table:{select update}> will also be checked
at the table level.
For sequences, db_sequence:get_value> is checked when we
reference a sequence object using SELECT>; however, note that we
do not currently check permissions on execution of corresponding functions
such as lastval()>.
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.
For functions, db_procedure:{execute}> is defined, but not
checked in this version.
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.
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
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>,
only setattr> should be checked here.
This is currently not checked due to implementation restrictions.
Trusted Procedure
Trusted procedures are similar to security definer functions or set-uid
commands. SELinux> provides a feature to allow trusted
code to run using a security label different from that of the client,
generally for the purpose of providing highly controlled access to
sensitive data (e.g. rows might be omitted, or the precision of stored
values might be reduced). Whether or not a function acts as a trusted
procedure is controlled by its security label and the operating system
security policy. For example:
postgres=# CREATE TABLE customer (
cid int primary key,
cname text,
credit text
);
CREATE TABLE
postgres=# SECURITY LABEL ON COLUMN customer.credit
IS 'system_u:object_r:sepgsql_secret_table_t:s0';
SECURITY LABEL
postgres=# CREATE FUNCTION show_credit(int) RETURNS text
AS 'SELECT regexp_replace(credit, ''-[0-9]+$'', ''-xxxx'', ''g'')
FROM customer WHERE cid = $1'
LANGUAGE sql;
CREATE FUNCTION
postgres=# SECURITY LABEL ON FUNCTION show_credit(int)
IS 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0';
SECURITY LABEL
The above operations should be performed by an administrative user.
postgres=# SELECT * FROM customer;
ERROR: SELinux: security policy violation
postgres=# SELECT cid, cname, show_credit(cid) FROM customer;
cid | cname | show_credit
-----+--------+---------------------
1 | taro | 1111-2222-3333-xxxx
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 the credit card number of customers with some of the digits masked
out.
Miscellaneous
We reject the command across the board, because
any module loaded could easily circumvent security policy enforcement.
Limitations
Userspace access vector cache
sepgsql> does not yet support an access vector cache.
This would likely improve performance.
Data Definition Language (DDL) Permissions
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
PostgreSQL> does not support row-level access; therefore,
sepgsql does not support it either.
Covert channels
sepgsql> never tries to hide existence of
a certain object, even if the user is not allowed to the reference.
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
of a top secret table cannot be hidden; we only hope to conceal its
contents.
External Resources
SE-PostgreSQL Introduction
This wiki page provides a brief-overview, security design, architecture,
administration and upcoming features.
Fedora SELinux User Guide
This document provides a wide spectrum of knowledge to administer
SELinux> on your systems.
It focuses primarily on Fedora, but is not limited to Fedora.
Fedora SELinux FAQ
This document answers frequently asked questions about
SELinux.
It focuses primarily on Fedora, but is not limited to Fedora.
Author
KaiGai Kohei kaigai@ak.jp.nec.com