SEPostgreSQL Introduction
This article provides comprehensive documentation for Security-Enhanced PostgreSQL (SE-PostgreSQL). SE-PostgreSQL is a built-in enhancement of PostgreSQL, providing additional access controls based on Security-Enhanced Linux (SELinux) security policy. The following chapters show the background, overview, design, and references (object classes, permissions, etc.) for SE-PostgreSQL.
- List of chapters
What is SE-PostgreSQL
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:
Mandatory access controls
PostgreSQL uses the concept of a database superuser that can bypass all access controls of native PostgreSQL. On the contrary, SE-PostgreSQL enforces its access control on any client, without exception, even if the client is a database superuser. Clients can only access database objects when access is allowed by both native PostgreSQL and SE-PostgreSQL, similar to the relationship between Discretionary Access Control (DAC) and Mandatory Access Control (MAC) on certain operating systems.
Fine-grained access controls
Granularity of access control depends on the RDBMS. SE-PostgreSQL allows access control to be configured at the column and row levels (only a few proprietary RDBMSs support column and row level access-control options).
Columns and rows are the smallest unit of database objects. Access control on these objects allows database administrators to apply flexible access control on them.
Consistency in access controls
SELinux requires all processes and objects to have a security context that represents its privileges and attributes. SE-PostgreSQL assigns a security context on each database objects (which are tuples in system/general tables), and makes access control decisions based on the privileges and attributes as if SELinux applies them in the kernel.
libselinux provides an interesting API named as getpeercon(), that enables you to get the security context of a peer process connecting to a server process. SE-PostgreSQL needs security contexts to make its decisions. This is a significant feature for consistency in access controls, in that privileges for clients and the attributes for objects are represented in the same form.
Why we need consistency in access controls
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.
LAPP/SELinux
It is our (middle term) vision in this project.
On the LAPP/SELinux stack, we can run web applications with more restrictive privileges to prevent violated accesses using application bugs or vulnerabilities. All the access control rules are centralized to the security policy of SELinux, and all the application behaviors are always checked by SELinux and SE-PostgreSQL (for database objects).
The LAPP/SELinux stack consists of SELinux(OS), SE-PostgreSQL(DB) and Apache/SELinux plus(web) now. In addition, we would like to enlarge its coverage to the application server layer.
- External links
- SELinux
- SELinux has been an upstreamed feature in the Linux kernel 2.6.x series and supported by major distributions (RedHatEL, Fedora and so on) for more than five years. It enables to apply fine-grained mandatory access controls on accesses to system resources.
- Reference policy
- It is the default security policy in the SELinux. It is managed and developed by SELinux community.
- It got SE-PostgreSQL support at the refpolicy-20070928 or later.
- Apache/SELinux plus
- It is an extra module of apache web server, which enables to launch web application instance with a specific security context based on http authentication. It allows OS/RDBMS to apply valid access controls for each web-users.
- It is packaged as mod_selinux at Fedora11 or later.
- PHP/SELinux
- It is a set of SELinux APIs for PHP script language. It provides interfaces to PHP scripts to communicate with SELinux.
- It is packaged as php-pecl-selinux at Fedora9 or later.
