When starting postgresql, it fails with the (little saying) error message:
pg_ctl: could not start server
In the denials, we notice:
Nov 24 10:41:52 lerya kernel: [1628900.540506] type=1400
audit(1353750112.021:10143): avc: denied { connectto } for pid=20481
comm="pg_ctl" path="/run/postgresql/.s.PGSQL.5432" ipaddr=...
scontext=system_u:system_r:postgresql_t tcontext=system_u:system_r:postgresql_t
tclass=unix_stream_socket
Hence, allow postgresql to connect to its own stream socket.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Use the init_daemon_run_dir interface in order to allow initrc_t to create the
run dirs of the postgresql service.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
* fix bugs in MLS/MCS
* add connection pooling server support
* foreign data wrapper support
* Add temporary objects support
* redefinition of use permission onto system objects
The attached patch allows postgresql_t domain to read selabel definition files
(such as /etc/selinux/targeted/contexts/sepgsql_contexts).
The upcoming version (v9.1) uses selabel_lookup(3) to assign initial security context
of database objects, we need to allow this reference.
Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei.kaigai@eu.nec.com>
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.htmlhttp://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
I found out a bug when we initialize the database with dbadm_r:dbadm_t
which belongs to sepgsql_admin_type attribute.
In the case when sepgsql_admin_type create a new database objects,
it does not have valid type_transition rules. So, it was failed.
Sorry, I didn't find out it for a long time.
And db_procedure:{execute} on the sepgsql_proc_exec_t might be necessary
for the administrative domain independently from sepgsql_unconfined_dbadm,
because we need to execute some of system defined procedures to look up
system tables.
"File context for /etc/sysconfig/pgsql and other bugs.
Sends audit messages connect to posgresql_server port
Reads its own process info"
Moved signal interface for style.
The attached patch allows unprivileged clients to export from or import
to the largeobject owned by themselves.
The current security policy does not allow them to import/export any
largeobjects without any clear reason.
NOTE: Export of the largeobject means that it dumps whole of the
largeobject into a local file, so SE-PostgreSQL checks both of
db_blob:{read export} on the largeobject and file:{write} on the
local file. Import is a reversal behavior.
KaiGai Kohei
The attached patch fixes incorrect behavior in sepgsql_enable_users_ddl.
The current policy allows users/unprivs to run ALTER TABLE statement
unconditionally, because db_table/db_column:{setattr} is allowed outside
of the boolean. It should be moved to conditional section.
In addition, they are also allowed to db_procedure:{create drop setattr}
for xxxx_sepgsql_proc_exec_t, but it means we allows them to create, drop
or alter definition of the functions unconditionally. So, it also should
be moved to conditional section.
The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
it should not be allowed.
KaiGai Kohei
OK, the attached patch adds the following types for unprivileged clients.
- unpriv_sepgsql_table_t
- unpriv_sepgsql_sysobj_t
- unpriv_sepgsql_proc_exec_t
- unpriv_sepgsql_blob_t
These types are the default for unprivileged and unprefixed domains,
such as httpd_t and others.
In addition, TYPE_TRANSITION rules are moved to outside of tunable
of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
tunable because UBAC domains (user_t and so on) were allowed to
create sepgsql_table_t, and its default was pointed to this type
when sepgsql_enable_users_ddl is disabled.
However, it has different meanings now, so the TYPE_TRANSITION rules
should be unconditional.
KaiGai Kohei
- rework: Add a comment of "deprecated" for deprecated permissions.
- bugfix: MCS policy did not constrain the following permissions.
db_database:{getattr}
db_table:{getattr lock}
db_column:{getattr}
db_procedure:{drop getattr setattr}
db_blob:{getattr import export}
- rework: db_table:{lock} is moved to reader side, because it makes
impossible to refer read-only table with foreign-key constraint.
(FK checks internally acquire explicit locks.)
- bugfix: some of permissions in db_procedure class are allowed
on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
It should allow them on sepgsql_trusted_proc_exec_t.
I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
procedure implicitly.
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.
Chris PeBenito
Sven Vermeulen
Chris PeBenito
Kohei Kaigai
Elia Pinto
KaiGai Kohei
Jeremy Solt