sepgsql 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 with --with-selinux. 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. This module has several prerequisites. Linux kernel v2.6.28 or later with built with SELinux enabled libselinux v2.0.80 or later This library provides a set of APIs to communicate with SELinux in kernel. selinux-policy v3.9.13 or later The default security policy provides a set of access control rules. Some distributions may backport necessary rules to older policy versions. sepgsql needs SELinux being available on the platform. You can check the current setting using sestatus. $ 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. 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 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. Adjust the paths shown below as appropriate for your installaton. $ initdb -D $PGDATA $ vi $PGDATA/postgresql.conf $ for DBNAME in template0 template1 postgres; do postgres --single -F -O -c exit_on_error=true -D $PGDATA $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. 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/ 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. 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. The meaning of the term "parent object" varies by object class, as follows. schema The parent object is the current database. table The parent object is the containing schema. column The parent object is the table. sequence The parent object is the containing schema. view The parent object is the containing schema. function The parent object is the containing schema. 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. The access rights of the client are checked 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 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. Here are 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. These operations are prohibited when sepgsql is enabled. 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 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. In this version, we reject the command across the board, because any module loaded could easily circumvent security policy enforcement. 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. 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. KaiGai Kohei (kaigai@ak.jp.nec.com)