sepgsql.zh.md

## F.37. sepgsql

[F.37.1. Overview](sepgsql.html#SEPGSQL-OVERVIEW)[F.37.2. Installation](sepgsql.html#SEPGSQL-INSTALLATION)[F.37.3. Regression Tests](sepgsql.html#SEPGSQL-REGRESSION)[F.37.4. GUC Parameters](sepgsql.html#SEPGSQL-PARAMETERS)[F.37.5. Features](sepgsql.html#SEPGSQL-FEATURES)[F.37.6. Sepgsql Functions](sepgsql.html#SEPGSQL-FUNCTIONS)[F.37.7. Limitations](sepgsql.html#SEPGSQL-LIMITATIONS)[F.37.8. External Resources](sepgsql.html#SEPGSQL-RESOURCES)[F.37.9. Author](sepgsql.html#SEPGSQL-AUTHOR)

[](<>)

`sepgsql`is a loadable module that supports label-based mandatory access control (MAC) based on SELinux security policy.

### Warning

The current implementation has significant limitations, and does not enforce mandatory access control for all actions. See[Section F.37.7](sepgsql.html#SEPGSQL-LIMITATIONS).

### F.37.1. Overview

This module integrates with SELinux to provide an additional layer of security checking above and beyond what is normally 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 in addition to the usual SQL 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, 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.

The[`SECURITY LABEL`](sql-security-label.html)statement allows assignment of a security label to a database object.

### F.37.2. Installation

`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.1.10 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. A typical display is:

```
$ 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 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[shared_preload_libraries](runtime-config-client.html#GUC-SHARED-PRELOAD-LIBRARIES)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.

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/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 -c exit_on_error=true $DBNAME \
      </usr/local/pgsql/share/contrib/sepgsql.sql >/dev/null
  done
```

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
```

These messages are harmless and should be ignored.

If the installation process completes without error, you can now start the server normally.

### F.37.3. Regression Tests

由于 SELinux 的性质，运行回归测试`sepgsql`需要几个额外的配置步骤，其中一些必须以 root 身份完成。回归测试不会由普通人运行`检查`要么`进行安装检查`命令;您必须设置配置，然后手动调用测试脚本。测试必须在`贡献/sepgsql`配置的 PostgreSQL 构建树的目录。尽管它们需要构建树，但测试旨在针对已安装的服务器执行，也就是说它们与`进行安装检查`不是`检查`.

首先，设置`sepgsql`根据中的说明在工作数据库中[第 F.37.2 节](sepgsql.html#SEPGSQL-INSTALLATION).请注意，当前操作系统用户必须能够以超级用户身份连接到数据库而无需密码验证。

其次，为回归测试构建和安装策略包。这`sepgsql-regtest`policy 是一个特殊用途的策略包，它提供了一组在回归测试期间允许使用的规则。它应该从策略源文件构建`sepgsql-regtest.te`，这是使用`制作`使用 SELinux 提供的 Makefile。你需要在你的系统上找到合适的 Makefile；下面显示的路径只是一个示例。（这个 Makefile 通常由`selinux-策略开发`或者`selinux-策略`RPM。）一旦构建，使用`模块`命令，它将提供的策略包加载到内核中。如果软件包安装正确，``模块`-l`应该列出`sepgsql-regtest`作为可用的政策包：

```
$ cd .../contrib/sepgsql
$ make -f /usr/share/selinux/devel/Makefile
$ sudo semodule -u sepgsql-regtest.pp
$ sudo semodule -l | grep sepgsql
sepgsql-regtest 1.07
```

三、开启`sepgsql_regression_test_mode`.出于安全原因，在`sepgsql-regtest`默认情况下不启用；这`sepgsql_regression_test_mode`参数启用启动回归测试所需的规则。可以使用`塞斯布尔`命令：

```
$ sudo setsebool sepgsql_regression_test_mode on
$ getsebool sepgsql_regression_test_mode
sepgsql_regression_test_mode --> on
```

四、验证你的shell是否在运行`无限制的_t`领域：

```
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
```

看[第 F.37.8 节](sepgsql.html#SEPGSQL-RESOURCES)有关调整工作域的详细信息（如有必要）。

最后，运行回归测试脚本：

```
$ ./test_sepgsql
```

此脚本将尝试验证您是否已正确完成所有配置步骤，然后它将运行回归测试`sepgsql`模块。

完成测试后，建议您禁用`sepgsql_regression_test_mode`范围：

```
$ sudo setsebool sepgsql_regression_test_mode off
```

You might prefer to remove the`sepgsql-regtest`policy entirely:

```
$ sudo semodule -r sepgsql-regtest
```

### F.37.4. GUC Parameters

`sepgsql.permissive`(`boolean`)[](<>)

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`file or on the server command line.

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.

`sepgsql.debug_audit`(`boolean`)[](<>)

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.

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.

### F.37.5. Features

#### F.37.5.1. Controlled Object Classes

The security model of SELinux describes all the access 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 unlabeled 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 a default security label, and is decided according to the system security policy, which takes as input the creator's label, the label assigned to the new object's parent object and optionally name of the constructed 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 tables, sequences, views, and functions, it is the containing schema; for columns, it is the containing table.

#### F.37.5.2. DML Permissions

For tables,`db_table:select`,`db_table:insert`,`db_table:update`or`db_table:delete`are 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 columns referenced in the`WHERE`or`RETURNING`clause, as a data source for`UPDATE`, and so on.

Column-level permissions will also be checked for each referenced column.`db_column:select`is checked on not only the columns being read using`SELECT`, but those being referenced in other DML statements;`db_column:update`或者`db_column：插入`还将检查被修改的列`更新`或者`插入`.

例如，考虑：

```
UPDATE t1 SET x = 2, y = func1(y) WHERE z = 100;
```

这里，`db_column：更新`将被检查`t1.x`, 因为它正在更新,`db_column:{选择更新}`将被检查`t1.y`，因为它既被更新又被引用，并且`db_column：选择`将被检查`t1.z`，因为它只被引用。`db_table:{选择更新}`也将在表级别进行检查。

对于序列，`db_sequence:get_value`当我们使用引用一个序列对象时检查`选择`;但是，请注意，我们目前不检查执行相应功能的权限，例如`最后一个（）`.

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}`will be checked when user tries to execute a function as a part of query, or using fast-path invocation. If this function is a trusted procedure, it also checks`db_procedure:{entrypoint}`permission to check whether it can perform as entry point of trusted procedure.

In order to access any schema object,`db_schema:search`permission is required on the containing schema. When an object is referenced without schema qualification, schemas on which this permission is not present will not be searched (just as if the user did not have`USAGE`privilege on the schema). If an explicit schema qualification is present, an error will occur if the user does not have the requisite permission on the named schema.

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.

#### F.37.5.3. DDL Permissions

SELinux defines several permissions to control common operations for each object type; such as creation, alter, drop and relabel of security label. In addition, several object types have special permissions to control their characteristic operations; such as addition or deletion of name entries within a particular schema.

Creating a new database object requires`create`permission. SELinux will grant or deny this permission based on the client's security label and the proposed security label for the new object. In some cases, additional privileges are required:

-   [`CREATE DATABASE`](sql-createdatabase.html)additionally requires`getattr`permission for the source or template database.

-   Creating a schema object additionally requires`add_name`对父架构的权限。

-   创建表还需要创建每个单独的表列的权限，就像每个表列是一个单独的顶级对象一样。

-   创建一个标记为的函数`防漏`另外需要`安装`允许。（此权限也被检查时`防漏`为现有功能设置。）

    什么时候`降低`命令被执行，`降低`将在被移除的对象上进行检查。还将检查通过间接删除的对象的权限`级联`.删除包含在特定模式（表、视图、序列和过程）中的对象还需要`删除名称`在架构上。

    什么时候`改变`命令被执行，`设置`将对每个对象类型的正在修改的对象进行检查，但附属对象（例如表的索引或触发器）除外，其中权限改为在父对象上检查。在某些情况下，需要额外的权限：

-   将对象移动到新模式还需要`删除名称`旧架构的权限和`添加名称`新的许可。

-   设置`LEAKPROOF`attribute on a function requires`install`permission.

-   Using[`SECURITY LABEL`](sql-security-label.html)on an object additionally requires`relabelfrom`permission for the object in conjunction with its old security label and`relabelto`permission for the object in conjunction with its new security label. (In cases where multiple label providers are installed and the user tries to set a security label, but it is not managed by SELinux, only`setattr`should be checked here. This is currently not done due to implementation restrictions.)

#### F.37.5.4. Trusted Procedures

Trusted procedures are similar to security definer functions or setuid 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
#### F.37.5.5. Dynamic Domain Transitions

 It is possible to use SELinux's dynamic domain transition feature to switch the security label of the client process, the client domain, to a new context, if that is allowed by the security policy. The client domain needs the `setcurrent` permission and also `dyntransition` from the old to the new domain.

 Dynamic domain transitions should be considered carefully, because they allow users to switch their label, and therefore their privileges, at their option, rather than (as in the case of a trusted procedure) as mandated by the system. Thus, the `dyntransition` permission is only considered safe when used to switch to a domain with a smaller set of privileges than the original one. For example:
```

regression=# select sepgsql_getcon();                     sepgsql_getcon

#### F.37.5.6. Miscellaneous

We reject the[`LOAD`](sql-load.html)command across the board, because any module loaded could easily circumvent security policy enforcement.

### F.37.6. Sepgsql Functions

[Table F.30](sepgsql.html#SEPGSQL-FUNCTIONS-TABLE)shows the available functions.

**Table F.30. Sepgsql Functions**

| Function<br/><br/>Description |
| ----------------------------- |
| `sepgsql_getcon`() →`文本`<br/><br/>返回客户端域，客户端的当前安全标签。 |
| `sepgsql_setcon`(`文本`) →`布尔值`<br/><br/>如果安全策略允许，则将当前会话的客户端域切换到新域。它也接受`空值`输入作为转换到客户端原始域的请求。 |
| `sepgsql_mcstrans_in`(`文本`) →`文本`<br/><br/>如果 mcstrans 守护程序正在运行，则将给定的合格 MLS/MCS 范围转换为原始格式。 |
| `sepgsql_mcstrans_out`(`文本`) →`文本`<br/><br/>如果 mcstrans 守护进程正在运行，则将给定的原始 MLS/MCS 范围转换为限定格式。 |
| `sepgsql_restorecon`(`文本`) →`布尔值`<br/><br/>为当前数据库中的所有对象设置初始安全标签。论据可能是`空值`, or the name of a specfile to be used as alternative of the system default. |

### F.37.7. Limitations

Data Definition Language (DDL) Permissions

Due to implementation restrictions, some DDL operations do not check permissions.

Data Control Language (DCL) Permissions

Due to implementation restrictions, DCL operations do not check permissions.

Row-level access control

PostgreSQL supports row-level access, but`sepgsql`does not.

Covert channels

`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 obtain the contents of the object. The existence of a top secret table cannot be hidden; we only hope to conceal its contents.

### F.37.8. External Resources

[SE-PostgreSQL Introduction](https://wiki.postgresql.org/wiki/SEPostgreSQL)

This wiki page provides a brief overview, security design, architecture, administration and upcoming features.

[SELinux User's and Administrator's Guide](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index)

This document provides a wide spectrum of knowledge to administer SELinux on your systems. It focuses primarily on Red Hat operating systems, but is not limited to them.

[Fedora SELinux FAQ](https://fedoraproject.org/wiki/SELinux_FAQ)

This document answers frequently asked questions about SELinux. It focuses primarily on Fedora, but is not limited to Fedora.

### F.37.9. Author

KaiGai Kohei`<[kaigai@ak.jp.nec.com](mailto:kaigai@ak.jp.nec.com)>`