Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Date: 2008-12-09 01:26:34
Message-ID: 493DC94A.6060306@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
>>>> Bruce Momjian wrote:
>>>>> I assume that could just be always enabled.
>>>> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
>>>> rest of enhanced security features (includes the row-level ACL) are
>>>> disabled automatically, as we discussed before.
>>> It seems like a pretty awful idea to have enabling sepostgres take away
>>> a feature that exists in the default build.
>> Why?
>>
>> The PGACE security framework allows one or no enhanced security
>> mechanism at most. It is quite natural that the default selection
>> is overrided when an alternative option is chosen explicitly.
>
> I'm finding these discussions very confusing to follow, sorry about
> that.
>
> We now have a parameter option that allows you to have row level
> security in non-mandatory mode, which is good. But in order to get that
> we need to build the server with a special configure option.

We need to distinguish a selection of enhanced security mechanism
and options provided by the mechanism chosen.

The PGACE security framework allows one or no enhanced security
mechanism at most when it is built. Thus, we have to determine
what mechanism to be activated. Currently, we have two enhanced
security mechanism for v8.4. The one is SE-PostgreSQL, and the
other is Row-level ACLs.

SE-PostgreSQL is a MAC-based feature which provides column/row
level granularity and collaboration with operating system.
It provides two GUC parameter options as follows:
- sepostgresql = (default|enforcing|permissive|disabled)
- sepostgresql_row_level = (on|off)

Row-level ACLs is a DAC-based feature which provides row level
granularity and works independently from operating system security.
It provides two table options as follows:
- row_level_acl = (on|off)
- default_row_acl = '<ACL text>'

> My previous objective was to remove the need for a configure option, so
> we can enable row-level security in the default distribution of
> Postgres. Are we going to enable that option in all normal distros? If
> yes, why is it a configure option (at all)?

The purpose of configure options is to choose a enhanced security
mechanism implemented on the PGACE security framework.
It is unclear for me what means the "row-level security" in this
context. Is it provided by SE-PostgreSQL? Row-level ACLs?

We currently have no option to disable all the enhanced security
mechanism, so one mechanism has to be choosen at least.
Both of the two mechanisms being available now provide row-level
granularity, so "row-level security" will be always enabled *in the
result*. Please note that it can be provided by different security
mechanism which is designed with independent security model.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2008-12-09 01:29:08 Re: V2 of PITR performance improvement for 8.4
Previous Message Tom Lane 2008-12-09 00:34:48 Re: Simple postgresql.conf wizard