Re: SE-PgSQL patch review - Mailing list pgsql-hackers

Itagaki Takahiro wrote:
> KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
> 
>>>   CREATE TABLE tbl (...) SECURITY CONTEXT '...'
>>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
>> to avoid syntax conflicts to "DEFAULT b_expr" option.
> 
> There might be another idea to put security context in WITH options:
>  1. CREATE TABLE tbl (...) WITH (security_context = '...')
>  2. CREATE TABLE tbl (col integer WITH (security_context = '...') PRIMARY KEY)
> If we use the syntax, '_' and '=' is reasonable.
> 
> BTW, I like to reverse the order of constraints and WITH options in
> column definitions (2), but I could not solve shift/reduce errors
> -- it might conflict with "PRIMARY KEY WITH (index-parameters)".

If we put "SECURITY CONTEXT" clause prior to the column constraints,
there are no syntax conflicts. However, it seems to me not intuitive.
 like, CREATE TABLE tbl (col int SECURITY CONTEXT '...' NOT NULL);

In addition, if we inject "security_context" in the relation options,
the way to fetch it is far different from other database objects.

Instead, what is your opinion for the syntax?
CREATE TABLE tbl (...) SECURITY CONTEXT ('label', col='label', ...);
When "col=" is omitted, it means an explicit security context of thenew table. Otherwise, it means an explicit one of
thegiven column.
 

And, for consistency,
CREATE DATABASE dbname SECURITY CONTEXT ('label');CREATE SCHEMA scname SECURITY CONTEXT ('label');


>> - sepgsql_template1_getcon -> pg_get_template1_secon
>> - sepgsql_database_getcon  -> pg_get_database_secon
> 
> Why do we need two version of functions for template1 and database?
> The template1 database is the default template for CREATE DATABASE,
> but we can also choose another one. Do we need to distinguish them?

They have different purposes.

The sepgsql_database_getcon() prints out a security context of the
database for the given OID in human-readable form.

The sepgsql_template1_getcon() returns a security context to be
assigned on the initial database from SELinux configuration.
Typically, it is configured at /etc/selinux/targeted/contexts/sepgsql_contexts.
If not exist, it asks SELinux a default security context as an initial
database.
Then, initdb uses the result to assign initial security context of the
managed database objects.

>>> * It uses dedicated 'SExxx' error codes, but I think they should belong to
>>>   the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501).
>> I already uses predefined error code, if exist.
> 
> What I meant was: there are no problem to add new error codes for SE-PgSQL,
> but I think the values of the codes should be '42xxx' because those errors
> are still "Class 42 - Access Rule Violation" from the view of users.

Ahh, OK. I'll fix it.

>>> ==== Internal structures ====
>>> * Are the security labels enough stable?
>>>   We store security labels as text for each object and column.
>> If the security labels get invalid due to the modification of SELinux
>> configuration or other reasons, it considers the database objects are
>> unlabeled.
> 
> I believe you have a plan to add row-level security checking in the future
> version. Do you have some documentation about how to implement security
> context for each row? I'm worrying about the on-disk representation.
> Security labels stored in text format takes 20-40 bytes per row. It is not
> negligibly-small, and might be hard to be treated because of variable-length.
> 
> We store OIDs for each row at the end of tuple header. If we also
> store securty labels in the same way, will we need some kinds of
> "securty label to OID" converter in the future?

Yes, it was contained in the earlier proposition with full-set functionalities.

http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog

In SELinux model, massive number of objects shares a limited number of
security context (e.g more than 100 tables may have a same one), this
design (it stores "security label OID" within the tuple header) is well
suitable for database objects.

BTW, I plan the following steps for the row-level security.
| * A facility to put "security label OID" within the tuple header.
| * System column support to print out the security context.
|   (This system column shall be writable to relabel)
| * Pure-SQL row-level security checks, something like Oracle Private
|   Database which allows user defined access control decision function.
| * SELinux aware row-level checks on the virtual private database stuff.
V   It can be implemented as one of the decision making functions.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>