Re: Updates of SE-PostgreSQL 8.4devel patches

Andrew Sullivan wrote:
> On Wed, Oct 08, 2008 at 11:36:19AM +0900, KaiGai Kohei wrote:
>> Yes, unfortunatelly.
>> No one replied to my proposed design:
>> http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2
>
> FWIW, I didn't know what to say about that proposal because I still
> don't know what problems any of this is trying to solve.

Please note that the above row-level permission works independently
and exclusively with SE-PostgreSQL. It simply applies DAC policy inside
RDBMS with per-tuple granuality, and will help fine-graned access
control independent from MAC polisy or operating system.

> 1. Single-policy access control for all objects available in a
> system. I'm guessing that this is the point of SE-PostgreSQL. It
> also appears to me that the SE-Linux approach may not have completely
> defined how these things work in a database context,

Its specification got a bit legacy now, so I have a plan to revise
it later, as Peter montioned before.

Indeed, SELinux does not define detailed behavior in database context
and it depends on architects. For example, we can implement column
level access control with replacing violated columns by NULL.
SE-PostgreSQL does not adopt such approach, but it was an option.
Perhaps, someone adopt this approach when he tries to make SE-MySQL. :-)

> 2. Granular row-level access control based on database-level ACLs. I
> have formed the impression that there is some support of this sort
> needed anyway to implement (1), but maybe not. I guess this is the
> proposal you mention.

As I mentioned at first, the row-level ACL does not intend to apply
a single unified security policy. It is an extention of existing
database-level ACL, and works independently from the philosophy of
SE-PostgreSQL.

> What is the goal here? Simply administrator-defined controls on
> data access inside the database?

Yes, it is a simple extention of existing ACL system to per-tuple
granuality, not something more than.

> 3. Column-level access controls. This is ruled out of the current
> discussion in the proposal mentioned above. Surely you need
> column-level access controls to make (1) work, though? If not, then
> I'm even more confused than I thought.

Now Stephen Frost is working for Column-level permission based on the
SQL standard, as a core facility of PostgreSQL.
The row-level permission is an optional facility, because we have no
standard to be refered. Please note that several major commercial RDBMS
also have its optional facility to provide row-level permission, like
Oracle Label Security, Oracle Virtual Private Database and DB2 LBAC.

> 4. Metadata-level access controls. None of the proposals so far seem
> to provide a complete set of access controls for the system details --
> schemas, databases, &c. Such controls are often requested, so I
> wonder about that.

We are already have GRANT/REVOKE on databases, schemaes and so on
as a core facility. This optional facility does not need to provide
it again.

> Please understand that I'm not trying to be obstructive, but at the
> moment I don't understand what the proposals aim to do. I suggest
> that, without some clear statements of what things are trying to do,
> and what the intended limitations are, it will always be impossible
> for anyone to review the implementation of such a big feature and say
> whether it does what it intends to do.

In my opinion, the row-level permission facility is a supplemental
facility between core PostgreSQL and SE-PostgreSQL.
It does not provide a single unified policy and MAC policy, but
enables to row-/column- level access controls with existing core
facilities.

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