SEPostgreSQL New

Overview

The Security Enhanced PostgreSQL (SE-PostgreSQL) is a contrib module that provides fine-grained mandatory access control based on the security policy of SELinux; that has been supported as contrib/sepgsql since PostgreSQL v9.1.

This feature enables to centralize access control rules towards data objects managed by operating system and database management system, and also allows to ensure consistency of them.

Background

Databases are significant facilities for managing information assets. Databases enable information to be searched for, retrieved, and stored in more elegant ways than with file systems.

Most existing RDBMSs apply their own access controls, for example, GRANT and REVOKE, without collaborating with operating system. This can result in inconsistent access controls compared to ones on filesystem and so on.

Some modern operating systems have enhanced access control features, such as SELinux. The design of most of these features is based upon the reference monitor model (which came from 1980's researches), that allows all system access to be managed by a centralized security policy. The reference monitor model assumes that object managers (for example, operating systems) can capture all system access, and then make decisions about whether that access is allowed or denied. Note: an operating systems is not the object manager in all cases. A Relational Database Management System (RDBMS) is an object manager for database objects, similar to operating systems being object managers for file system objects. Previously, RDBMSs made access control decisions independently from a centralized security policy, and as such, meticulous care to keep its consistency between OS and RDBMS. SE-PostgreSQL is a built-in enhancement of PostgreSQL, providing fine-grained mandatory access control (MAC) for database objects. SE-PostgreSQL makes access control decisions based on SELinux security policy, the same way user access to file system objects is managed by the operating system. It provides the following significant features:

Data-Flow Control

Consider RDBMSs (including PostgreSQL) as an inter-process communication channel, the same as file systems, networks, IPC, and so on. The most significant purpose for security mechanisms is to protect classified information being leaked. On subsystems with individual access controls -- not a centralized one -- an attacker can choose the weakest inter-process communication channel. SELinux is an operating system feature that applies a single, unified security policy over the whole operating system. System calls are intercepted and inspected. This approach allows policy to be enforced with minimal costs; however, keep in mind that several user-space object managers, such as the X Window System and RDBMSs, can be used as inter-process communication channels. Resources managed in user-space are invisible to the kernel, leaving two options for security policy: the traditional all-or-nothing policy, that does not allow user-space objects to be shared (this is unrealistic), or the enhancement of user-space object managers, making their access control decisions based on the single, unified security policy of SELinux.

The above figure demonstrates consistent data-flow controls. It requires that classified information (Higher Sensitivity Level Domain) does not leak to unclassified domains (Lower Sensitivity Level Domain) via inter-process communication channels, whether those channels are networks, RDBMSs, and so on. In this example, when a user with clearance logs in, their user process is labeled with SystemHigh, allowing them access to secret information labeled with Secret. In contrast, when a user without clearance logs in, their user process is labeled with SystemLow, preventing them access to secret information labeled with Secret. In addition, SystemHigh processes are prohibited from sending messages to SystemLow processes. These restrictions are independent from the type of inter-process communication channel being used (restrictions apply to the whole operating system). In accordance to security policy, SELinux prevents user processes without clearance from reading secret information stored in objects managed by the Linux kernel, as well as preventing user processes with clearance from writing secret information to unclassified objects.

Solutions

- LAPP/SELinux

- Restricted DBA -- Need figures

References

List of Permissions

SELinux represents its access permissions as a combination of object class and access vectors. The object class means the kind of objects, such as file, dir, tcp_socket and so on. All the available operations on a certain object depends on the type of the object, we cannot send a packet on a directory for instance, so the security poilcy defines a specific set of permissions for each object classes. We call them as access vectors.

This table introduces all the object classes and access vectors for database objects, currently we have.

Object classes and access vectors

db_database	db_tablespace	db_schema	db_schema_temp	db_table	db_sequence	db_procedure	db_column	db_tuple	db_blob
create	create	create	create	create	create	create	create		create
drop	drop	drop	drop	drop	drop	drop	drop		drop
getattr	getattr	getattr	getattr	getattr	getattr	getattr	getattr		getattr
setattr	setattr	setattr	setattr	setattr	setattr	setattr	setattr		setattr
relabelfrom	relabelfrom	relabelfrom	relabelfrom	relabelfrom	relabelfrom	relabelfrom	relabelfrom	relabelfrom	relabelfrom
relabelto	relabelto	relabelto	relabelto	relabelto	relabelto	relabelto	relabelto	relabelto	relabelto
access	createon	search	search	select	get_value	execute	select	select	read
load_module		add_name	add_name	update	next_value	entrypoint	update	update	write
superuser		remove_name	remove_name	insert	set_value	install	insert	insert	import
				delete		untrusted		delete	export
				lock

common database class

Some of access vectors are universal for database objects, so they are included within these object classes commonly. We introduces them (create, drop, getattr, setattr, relabelfrom and relabelto) in this section.

create

It is required on the database objects newly created, usinf CREATE xxx statement typically.

When we create new database objects, SE-PostgreSQL assigns a default security context (if no explicit one is not given) on them, then checks client's privileges on them with the default security context.

For example, when a user tries to create a new table, it may assign system_u:object_r:sepgsql_table_t:s0 on the new table, and checks user's db_table:{create} permission. If not allowed, SE-PostgreSQL prevents to execute the given query any more.

drop

It is required on the database objects to be dropped, using DROP xxx statement typically.

getattr

It is required on the database objects to be refered, using SELECT ... FROM <system catalog> statement typically.

setattr

It is required on the database objects to be updated, using ALTER xxx statement typically.

relabelfrom

It is required on the database objects with older security context, when we change the security context of them.

relabelto

It is required on the database obejcts with newer security context, when we change the security context of them.

db_database class

The db_database class represents the database object itself, and inherits the common database object class, so it has the common six access vectors.

The default security context

A database object performs as a root of TYPE_TRANSITION for any other database object. Thus, it does not have any parent object.

When the security policy gives a default context, SE-PostgreSQL tries to assign it. Its configuration can be stored at /etc/selinux/${POLICYTYPE}/contexts/sepgsql_context.

If no configuration given, it inherits the security context of the client process. However, the default security policy has TYPE_TRANSITION rules on them, so all the new databases will be labeled as sepgsql_db_t.

access

It is required when a client connects to a certain database. It performs as an analogy of ACL_CONNECT on the database acl mechanism.

load_module

It is required when a dynamic link library is loaded to the current address space.

The current database (not a client) needs to be allowed to load the library.

Please note that it is checked when a DLL is loaded, different from the db_database:{install_module}.

superuser

It is required when a client performs as a superuser on the database.

If the permission is not allowed, the client cannot perform as superuser, but SE-PostgreSQL does not raises an error. He can just perform as a non-privileged database user.

db_tablespace class

createon

It is required when a client tries to create something on the target tablespace.

db_schema class

The db_schema class represents schema object (not a temporary one), and inherits the common database object class, so it has the common six access vectors.

The default security context

It inherits the security context of the database where the schema object deployed on.

search

It is required when a client refers a database object within a certain schema object. It performs as an analogy of ACL_USAGE on schema objects.

add_object

It is required when a client creates a database object within a certain schema object.

remove_object

It is required when a client drops a database object within a certain schema object.

db_schema_temp class

The db_schema_temp class represents temporary scheme objects, and inherits the common database object class, so it has the common six access vectors.

The default security context

same as db_schema class.

search (not implemented now)

It should be required when a client refers a database object within a certain schema object.

add_object

same as db_schema:{add_object}

remove_object

same as db_schema:{remove_object}

db_table class

The db_table class represents regular table objects, and inherits the common database object class, so it has the common six access vectors.

The default security context

It inherits the security context of the schema where the table object deployed on.

The default policy has a few TYPE_TRANSITION rules on db_table class, so a new table will be labeled as sepgsql_table_t, user_sepgsql_table_t or unpriv_sepgsql_table_t.

select

It is required on the table to be refered via SELECT or COPY TO statement and others which contains any references such as RETURNING clause.

Please note that we can consider a reference within WHERE, ORDER BY and other clauses also require db_table:{select} permission, although it does not return the contents directly.

update

It is required on the table to be updated via UPDATE statement.

insert

It is required on the table to be inserted via INSERT or COPY FROM statement.

delete

It is required on the table to be deleted via DELETE or TRUNCATE statement.

lock

It is required on the table to be locked explicitly via LOCK statement, or SELECT ... FOR UPDATE/SHARE statement.

Please note that it is not required on implicit table locks.

db_procedure class

The db_procedure class represents SQL functions, and inherits the common database object class, so it has the common six access vectors.

The default security context

It inherits the security context of the schema where the SQL functions deployed on.

The default policy has a few TYPE_TRANSITION rules on db_procedure class, so a new table will be labeled as sepgsql_proc_exec_t, user_sepgsql_proc_exec_t or unpriv_sepgsql_proc_exec_t.

execute

It is required on the procedure to be executed. It performs as an analogy of ACL_EXECUTE on the database acl mechanism.

entrypoint

It is required on the procedure to be executed as a trusted procedure.

See the PUT HERE A PROPER URL for more details.

Trusted procedures causes a domain transition, so the process:{transition} also needs to be allowed.

The following policies are necessary when a client (staff_t) invokes a trusted procedure (sepgsql_trusted_proc_exec_t) that causes domain transition to sepgsql_trusted_proc_t.

Please note that we don't support to use built-in functions as trusted procedures due to implementation reason.

allow staff_t sepgsql_trusted_proc_exec_t : db_procedure { execute entrypoint };

allow staff_t sepgsql_trusted_proc_t : process { transition };

type_transition staff_t sepgsql_trusted_proc_exec_t : db_procedure sepgsql_proc_t;

install

It is required on the procedures to be installed as a part of system internal stuffs.

PostgreSQL invokes user defined functions as a part of server internal stuffs, so SE-PostgreSQL checks its correctness on its installation time.

untrusted

It is required on the creation of procedures which uses untrusted language, in addition to db_procedure:{create}

db_sequence class

The db_sequence class represents sequence objects, and inherits the common database object class, so it has the common six access vectors.

The default security context

It inherits the security context of the schema where the sequence obejct deployed on.

get_value

It is required on the sequence to be refered without any changes.

next_value

It is required on the sequence to be refered with an increment of the value.

set_value

It is required on the sequence to be set a given value.

db_column class

The db_column class represents table column objects, and inherits the common database object class, so it has the common six access vectors.

The default security context.

It inherits the security context of the table which contains the conlumn.

select

It is required on the column which is referred via SELECT or COPY TO statement and others which contains any references such as RETURNING clause.

update

It is required on the column which is listed on UPDATE statement.

insert

It is required on the column which is listed on INSERT or COPY FROM statement.

db_tuple class

The db_tuple class represents tuples within a regular tables, and it contains six access vectors.

The default security context

It inherits the security context of the table which contains the tuple.

relabelfrom

It is required on the tuple with older context when it is relabeled.

relabelto

It is required on the tuple with newer context when it is relabeled.

select

It is required on the tuple to be selected.

update

It is required on the tuple to be updated.

insert

It is required on the tuple to be inserted.

delete

It is required on the tuple to be deleted.

db_blob class

The db_blob class represents binary large objects, and inherits the common database object class, so it has the common six access vectors.

The default security context

It inherits the security context of the database.

The default policy has a few TYPE_TRANSITION rules on db_blob class, so a new largeobject will be labeled as sepgsql_blob_t, user_sepgsql_blob_t or unpriv_sepgsql_blob_t.

read

It is required on the largeobject to be read with loread() or lo_export().

write

It is required on the largeobject to be written with lowrite(), lo_truncate() or lo_import().

import

It is required on the largeobject to be imported with lo_import() function, not only db_blob:{write}.

Please note that a largeobject is created with a default security context, so this permission is checked on the default one.

export

It is required on the largeobject to be exported with lo_export() function, not only db_blob:{read}.