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
= Architecture =
= SELinux =
= Specification =
= Administration =
= Default Policy =
= 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}.
== List of Functions ==
= Limitations =
Category:SELinux