Re: Updates of SE-PostgreSQL 8.4devel patches

I updated the series of patches for SE-PostgreSQL 8.4devel.

[1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch
[2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch
[3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1043.patch
[4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1043.patch
[5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1043.patch

The newly added fifth patch contains the initial version of SE-PostgreSQL
testcases, and sepostgresql-devel security policy got several new rules
to invoke the test cases.
In addition, I also fixed the following items.
- bugfix: A case when we insert a tuple with FK refering invisible PK.
- mispatch: The previous patch modified unrelated document files due to
my misoperation when create patches.
- rebase: I rebased toward to latest CVS HEAD.

I hope to make progress reviewing process in parallel with the upcoming
"fine-grained security" patch which is currently in designing.

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

The following proposal is idea which I have been considered for several days.

A design of PostgreSQL fine-grained security
--------------------------------------------

* Target

This feature provide a row-level access control feature based on
database acl. Any tuple can have its access control list as table
having, and it is checked when the executor scan the tuple.
The violated tuples are filtered from the result set.

This feature does not provide a column-level access control feature,
because its effort is already in development, and it has SQL standards
to be refered.
But there is no standard for row-level security as far as I know,
so these features should be provided in separated.

* Security architecture

Its access control policy is based on database acl which is a kind of
discretional access control (DAC). It implicitly allows resource owner
or privileged users to change its access rights.
As an existing mechanism doing, privileged database roles can ignore
row-level access controls provided by this feature.

The resource owner of tuple should be a same as table owner, because
we have to massive number of pg_depend entries if individual tuple has
its owner. In addition, here is one more reason related to kinds of
permissions.

Three kind of permissions are provided for tuples. These are SELECT,
UPDATE and DELETE. The violated tuples are filtered out from the result
set of DML statement.
The "INSERT" permission is not provided, because an object does not exist
when the permission should be checked. All insertion of tuples are controled
by database acl of table. Since table owner is always same as tuple's one,
there is no administrative matter.

When we insert a tuple without any explicit acl, an empty acl is assigned.
It allows any kinds of accesses. Only owner can insert a tuple with explicit
acl.

* Implementation

This feature is implemented as a guest of PGACE security framework due to
the following two reasons.
The one is we don't have a standard for row-level security to be refered,
so it is more appropriate to be implemented as an "enhanced" security
mechanism.
The other is it provides several useful foundation to implement enhanced
security feature, like security system column support. We have to store
a database acl for each tuples which have characteristics massive objects
tend to share a small number of acls. The PGACE enables to represent it
with minimum cost.

The following image shows a concept of security system column.

kaigai=# SELECT pg_tuple_acl, * FROM drink;
+--------------------------------+----+--------+-------+
| pg_tuple_acl | id | name | price |
+--------------------------------+----+--------+-------+
| {kaigai=rwd/kaigai,=ar/kaigai} | 1 | coke | 130 |
| {} | 2 | juice | 150 |
| {kaigai=rwd/kaigai,=rw/kaigai} | 3 | coffee | 200 |
| : | : | : | : |

The security system column is writable. The owner can set per-tuple acl
with UPDATE or INSERT statement. The acl statement is a bit complicated,
so the following two functions helps to modify acl.

pg_tuple_acl_grant(text original, text role, text permissions)
pg_tuple_acl_revoke(text original, text role, text permissions)

For example:
UPDATE drink SET pg_tuple_acl = pg_tuple_acl_grant(pg_tuple_acl, 'bob', 'select,update');
WHERE id in (5,6,7);

One limitation is we can use this feature exclusively with SE-PostgreSQL.
But, I think user's requirements are different.

* Special cases

This feature does not allow to assign ACLs to tuples within system catalogs
to prevent inconsistency with existing access control mechanism.

When a user tries to insert a tuple with duplicate PK, it is failed
independent from its visibility.

When a user tries to insert a new tuple with FK, the refered PK have to
be visible for the owner of refered table, because FK triggers are invoked
with owner's identifier. In similar case, when a user tries to update or
delete a tuple with PK, the owner of refering table have to be able to
perform pre-defined action (like SET NULL).

* Backup/Restore

I'll add '--enable-tuple-acl' option to pg_dump/pg_dumpall.
It enables to dump tables with defined acls, and they can be restored via
writable security system column.

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

KaiGai Kohei wrote:
> The following proposal is idea which I have been considered for several days.
>
> A design of PostgreSQL fine-grained security
> --------------------------------------------
>
> * Target
>
> This feature provide a row-level access control feature based on
> database acl. Any tuple can have its access control list as table
> having, and it is checked when the executor scan the tuple.
> The violated tuples are filtered from the result set.
>
> This feature does not provide a column-level access control feature,
> because its effort is already in development, and it has SQL standards
> to be refered.
> But there is no standard for row-level security as far as I know,
> so these features should be provided in separated.
>
>
> * Security architecture
>
> Its access control policy is based on database acl which is a kind of
> discretional access control (DAC). It implicitly allows resource owner
> or privileged users to change its access rights.
> As an existing mechanism doing, privileged database roles can ignore
> row-level access controls provided by this feature.
>
> The resource owner of tuple should be a same as table owner, because
> we have to massive number of pg_depend entries if individual tuple has
> its owner. In addition, here is one more reason related to kinds of
> permissions.
>
> Three kind of permissions are provided for tuples. These are SELECT,
> UPDATE and DELETE. The violated tuples are filtered out from the result
> set of DML statement.
> The "INSERT" permission is not provided, because an object does not exist
> when the permission should be checked. All insertion of tuples are controled
> by database acl of table. Since table owner is always same as tuple's one,
> there is no administrative matter.
>
> When we insert a tuple without any explicit acl, an empty acl is assigned.

I will changes this design.
It is useful to provide an interface to set up default row acl, like:

ALTER TABLE t1 DEFAULT_ROW_ACL='{kaigai=rwd/kaigai,ymj=r/kaigai}';

Please any comments,

Thanks

> It allows any kinds of accesses. Only owner can insert a tuple with explicit
> acl.
>
>
> * Implementation
>
> This feature is implemented as a guest of PGACE security framework due to
> the following two reasons.
> The one is we don't have a standard for row-level security to be refered,
> so it is more appropriate to be implemented as an "enhanced" security
> mechanism.
> The other is it provides several useful foundation to implement enhanced
> security feature, like security system column support. We have to store
> a database acl for each tuples which have characteristics massive objects
> tend to share a small number of acls. The PGACE enables to represent it
> with minimum cost.
>
> The following image shows a concept of security system column.
>
> kaigai=# SELECT pg_tuple_acl, * FROM drink;
> +--------------------------------+----+--------+-------+
> | pg_tuple_acl | id | name | price |
> +--------------------------------+----+--------+-------+
> | {kaigai=rwd/kaigai,=ar/kaigai} | 1 | coke | 130 |
> | {} | 2 | juice | 150 |
> | {kaigai=rwd/kaigai,=rw/kaigai} | 3 | coffee | 200 |
> | : | : | : | : |
>
> The security system column is writable. The owner can set per-tuple acl
> with UPDATE or INSERT statement. The acl statement is a bit complicated,
> so the following two functions helps to modify acl.
>
> pg_tuple_acl_grant(text original, text role, text permissions)
> pg_tuple_acl_revoke(text original, text role, text permissions)
>
> For example:
> UPDATE drink SET pg_tuple_acl = pg_tuple_acl_grant(pg_tuple_acl, 'bob', 'select,update');
> WHERE id in (5,6,7);
>
> One limitation is we can use this feature exclusively with SE-PostgreSQL.
> But, I think user's requirements are different.
>
>
> * Special cases
>
> This feature does not allow to assign ACLs to tuples within system catalogs
> to prevent inconsistency with existing access control mechanism.
>
> When a user tries to insert a tuple with duplicate PK, it is failed
> independent from its visibility.
>
> When a user tries to insert a new tuple with FK, the refered PK have to
> be visible for the owner of refered table, because FK triggers are invoked
> with owner's identifier. In similar case, when a user tries to update or
> delete a tuple with PK, the owner of refering table have to be able to
> perform pre-defined action (like SET NULL).
>
> * Backup/Restore
>
> I'll add '--enable-tuple-acl' option to pg_dump/pg_dumpall.
> It enables to dump tables with defined acls, and they can be restored via
> writable security system column.
>
> Thanks,

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

KaiGai Kohei wrote:
> I updated the series of patches for SE-PostgreSQL 8.4devel.
>
> [1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch
> [2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch
> [3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1043.patch
> [4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1043.patch
> [5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1043.patch

I looked over the patches listed above. They have line counts listed
below:

10759 sepostgresql-sepgsql-8.4devel-3-r1043.patch
616 sepostgresql-pg_dump-8.4devel-3-r1043.patch
826 sepostgresql-policy-8.4devel-3-r1043.patch
1237 sepostgresql-docs-8.4devel-3-r1043.patch
836 sepostgresql-tests-8.4devel-3-r1043.patch
14274 total

Particularly interesting was the doc patch,
sepostgresql-docs-8.4devel-3-r1043.patch. It explains how SE-PostgreSQL
checks the permission level of the client process (getpeercon) and uses
that to determine what the user should see. Also interesting is how a
new row-level system permission column references a new table
'pg_security', which holds security credentials for the row.

The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch,
which modifies the backend. About 30% of it or 3k lines modify our
backend, and the rest are indepdendent support routines in their own C
files.

So, I am now reevaluating how we should proceed with this patch.

I think we know we want column-level permissions and that is being
worked on, so it should reduce the size of the 3k part of that patch
slightly.

As far as backend changes the largest part is the row-level permissions.
Do we want row-level permissions to be accessible at the SQL level,
perhaps optionally, by having a role be associated with a row, and only
role members can see it. If we do, and implement it, the 3k part is
reduced significantly.

FYI, SE-PostgreSQL sets _row_ permissions by assigning to the new
permissions system column:

INSERT INTO drink (security_context, id, name, price)
VALUES('system_u:object_r:sepgsql_table_t:SystemHigh', 7, 'tea', 130);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That string is what is placed in 'pg_security' and a reference to is
placed on the row.

The other conclusion I came to is that the other 11k of patch is really
independent SE-Linux interface code and not likely to change in size no
matter what we implement at the SQL level.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> I updated the series of patches for SE-PostgreSQL 8.4devel.
>>
>> [1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch
>> [2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch
>> [3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1043.patch
>> [4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1043.patch
>> [5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1043.patch
>
> I looked over the patches listed above. They have line counts listed
> below:
>
> 10759 sepostgresql-sepgsql-8.4devel-3-r1043.patch
> 616 sepostgresql-pg_dump-8.4devel-3-r1043.patch
> 826 sepostgresql-policy-8.4devel-3-r1043.patch
> 1237 sepostgresql-docs-8.4devel-3-r1043.patch
> 836 sepostgresql-tests-8.4devel-3-r1043.patch
> 14274 total
>
> Particularly interesting was the doc patch,
> sepostgresql-docs-8.4devel-3-r1043.patch. It explains how SE-PostgreSQL
> checks the permission level of the client process (getpeercon) and uses
> that to determine what the user should see.

Yes, this is a significant point which tends to be misunderstood.
When two processes with individual security context on operating system
connect to SE-PostgreSQL, they will get individual result, even if they
logged in as a same database role.

> Also interesting is how a
> new row-level system permission column references a new table
> 'pg_security', which holds security credentials for the row.
>
> The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch,
> which modifies the backend. About 30% of it or 3k lines modify our
> backend, and the rest are indepdendent support routines in their own C
> files.

The 3k lines (which is named as PGACE security framework) part was provided
as separated patches, but I was pointed out it requires reviewers to see
two files in same time. So, these were integrated into one.

> So, I am now reevaluating how we should proceed with this patch.
>
> I think we know we want column-level permissions and that is being
> worked on, so it should reduce the size of the 3k part of that patch
> slightly.
>
> As far as backend changes the largest part is the row-level permissions.
> Do we want row-level permissions to be accessible at the SQL level,
> perhaps optionally, by having a role be associated with a row, and only
> role members can see it. If we do, and implement it, the 3k part is
> reduced significantly.
>
> FYI, SE-PostgreSQL sets _row_ permissions by assigning to the new
> permissions system column:
>
> INSERT INTO drink (security_context, id, name, price)
> VALUES('system_u:object_r:sepgsql_table_t:SystemHigh', 7, 'tea', 130);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> That string is what is placed in 'pg_security' and a reference to is
> placed on the row.

Yes, it looks like every tuple has text formatted security attribute,
but they hold an Oid value of pg_security system catalog.
Because this feature is provided by common foundation, any other
security features can also use the system column for its purpose
(like storing row-level database acl now in development).

> The other conclusion I came to is that the other 11k of patch is really
> independent SE-Linux interface code and not likely to change in size no
> matter what we implement at the SQL level.

Yes, the primary purpose of this archtecture is to minimize the impact
for the core PostgreSQL implementation, when user choose an enhanced
security mechanism.

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

KaiGai Kohei wrote:
> > Particularly interesting was the doc patch,
> > sepostgresql-docs-8.4devel-3-r1043.patch. It explains how SE-PostgreSQL
> > checks the permission level of the client process (getpeercon) and uses
> > that to determine what the user should see.
>
> Yes, this is a significant point which tends to be misunderstood.
> When two processes with individual security context on operating system
> connect to SE-PostgreSQL, they will get individual result, even if they
> logged in as a same database role.

Yes, that was very clear in your documentation.

> > The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch,
> > which modifies the backend. About 30% of it or 3k lines modify our
> > backend, and the rest are indepdendent support routines in their own C
> > files.
>
> The 3k lines (which is named as PGACE security framework) part was provided
> as separated patches, but I was pointed out it requires reviewers to see
> two files in same time. So, these were integrated into one.

Ah, OK. I think we need to decide:

1) When are we getting column-level permissions that you can
plug into?
2) Do we want row-level permissions at the SQL level?

> > The other conclusion I came to is that the other 11k of patch is really
> > independent SE-Linux interface code and not likely to change in size no
> > matter what we implement at the SQL level.
>
> Yes, the primary purpose of this archtecture is to minimize the impact
> for the core PostgreSQL implementation, when user choose an enhanced
> security mechanism.

Yes, you have certainly done that well.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
>>> The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch,
>>> which modifies the backend. About 30% of it or 3k lines modify our
>>> backend, and the rest are indepdendent support routines in their own C
>>> files.
>> The 3k lines (which is named as PGACE security framework) part was provided
>> as separated patches, but I was pointed out it requires reviewers to see
>> two files in same time. So, these were integrated into one.
>
> Ah, OK. I think we need to decide:
>
> 1) When are we getting column-level permissions that you can
> plug into?

Please note that SE-PostgreSQL checks its column-level permission *after* VIEWs
are expanded, because it focuses on "what" object is accessed, not "how".
Thus, it walks on the query tree just after QueryRewrite() to pick up columns
to be refered in this query.
The term is same, but it's unclear for me whether it can share the code based
on SQL standards, or not.
(In my opinion, it is not a matter, just a difference in security model.)

> 2) Do we want row-level permissions at the SQL level?

Now I'm working for it and will submit patches due to the end of Oct,
if it is really required to make progress reviewing of SE-PostgreSQL
on the v8.4 development cycle.
However, the scale of its demand is unclear for me.

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

KaiGai Kohei wrote:
> > 1) When are we getting column-level permissions that you can
> > plug into?
>
> Please note that SE-PostgreSQL checks its column-level permission *after* VIEWs
> are expanded, because it focuses on "what" object is accessed, not "how".
> Thus, it walks on the query tree just after QueryRewrite() to pick up columns
> to be refered in this query.
> The term is same, but it's unclear for me whether it can share the code based
> on SQL standards, or not.
> (In my opinion, it is not a matter, just a difference in security model.)

I understand.

> > 2) Do we want row-level permissions at the SQL level?
>
> Now I'm working for it and will submit patches due to the end of Oct,
> if it is really required to make progress reviewing of SE-PostgreSQL
> on the v8.4 development cycle.
> However, the scale of its demand is unclear for me.

Yes, which is why I would like the community to answer the question
before you have to start coding things. I will say that if we do want
it, the SE-Linux code will be 96% in separate modules and will make it
much easier to accept.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
>> > 2) Do we want row-level permissions at the SQL level?
>>
>> Now I'm working for it and will submit patches due to the end of Oct,
>> if it is really required to make progress reviewing of SE-PostgreSQL
>> on the v8.4 development cycle.
>> However, the scale of its demand is unclear for me.
>
> Yes, which is why I would like the community to answer the question
> before you have to start coding things. I will say that if we do want
> it, the SE-Linux code will be 96% in separate modules and will make it
> much easier to accept.

OK, I'll stop my hand today, and wait for pgsql-hacker's opinions.

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

KaiGai Kohei wrote:
> Bruce Momjian wrote:
> >> > 2) Do we want row-level permissions at the SQL level?
> >>
> >> Now I'm working for it and will submit patches due to the end of Oct,
> >> if it is really required to make progress reviewing of SE-PostgreSQL
> >> on the v8.4 development cycle.
> >> However, the scale of its demand is unclear for me.
> >
> > Yes, which is why I would like the community to answer the question
> > before you have to start coding things. I will say that if we do want
> > it, the SE-Linux code will be 96% in separate modules and will make it
> > much easier to accept.
>
> OK, I'll stop my hand today, and wait for pgsql-hacker's opinions.

Here is how I think SQL-level row permissions would work:

We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SECURITY) called security_context which would store the
oid of the role that can see the row; if the oid is zero (InvalidOid),
anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
use the oid to look up strings in pg_security.

Is this something we want for non-SE-PostgreSQL builds? SE-PostgreSQL
would still be a compile-time option because of all the additional
SE-Linux support code.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Here is how I think SQL-level row permissions would work:

> We already have an optional OID system column that can be specified
> during table creation (WITH OIDS). We could have another optional oid
> column (WITH ROW SECURITY) called security_context which would store the
> oid of the role that can see the row; if the oid is zero (InvalidOid),
> anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
> use the oid to look up strings in pg_security.

This is just a different syntax for KaiGai's label storage
implementation. It doesn't really answer any of the hard questions,
like what the heck is the behavior of foreign keys.

regards, tom lane

> This is just a different syntax for KaiGai's label storage
> implementation. It doesn't really answer any of the hard questions,
> like what the heck is the behavior of foreign keys.

What do you find inadequate about KaiGai's answers to those hard questions?

...Robert

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Here is how I think SQL-level row permissions would work:
>
> > We already have an optional OID system column that can be specified
> > during table creation (WITH OIDS). We could have another optional oid
> > column (WITH ROW SECURITY) called security_context which would store the
> > oid of the role that can see the row; if the oid is zero (InvalidOid),
> > anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
> > use the oid to look up strings in pg_security.
>
> This is just a different syntax for KaiGai's label storage
> implementation. It doesn't really answer any of the hard questions,
> like what the heck is the behavior of foreign keys.

Well, the PGACE documentation says:

http://code.google.com/p/sepgsql/wiki/WhatIsPGACE

Datum pgacePreparePlanCheck(Relation rel)

It is invoked just before calling a function which implements fereign
key constraint.

The major purpose of this hook is to keep consistency in the lowest
level. It enables to notify the guest the beginning of checks in foreign
key constraint. The guest can change the behavior of tuple level access
control between pgacePreparePlanCheck() and pgaceRestorePlanCheck().

--> In SE-PostgreSQL case, access controls in tuple level are normally done
with filtering any violated tuple. However, it can prevent to check
foreign key constraint, because caller cannot recognize whether no tuple
refers the primary relation, or any tuple refering are filtered.
Therefore, SE-PostgreSQL aborts the current transaction if any violated
tuple refering the primary relation.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

> Here is how I think SQL-level row permissions would work:
>
> We already have an optional OID system column that can be specified
> during table creation (WITH OIDS). We could have another optional oid
> column (WITH ROW SECURITY) called security_context which would store the
> oid of the role that can see the row; if the oid is zero (InvalidOid),
> anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
> use the oid to look up strings in pg_security.

I like the idea of a WITH ROW SECURITY option to enable row-level
security - that way, tables that don't need it don't have to pay for
it, but I like the idea of storing a full ACL, as KaiGai proposed,
rather than just a single role. Seems much more powerful.

...Robert

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> Bruce Momjian wrote:
>>>> > 2) Do we want row-level permissions at the SQL level?
>>>>
>>>> Now I'm working for it and will submit patches due to the end of Oct,
>>>> if it is really required to make progress reviewing of SE-PostgreSQL
>>>> on the v8.4 development cycle.
>>>> However, the scale of its demand is unclear for me.
>>> Yes, which is why I would like the community to answer the question
>>> before you have to start coding things. I will say that if we do want
>>> it, the SE-Linux code will be 96% in separate modules and will make it
>>> much easier to accept.
>> OK, I'll stop my hand today, and wait for pgsql-hacker's opinions.
>
> Here is how I think SQL-level row permissions would work:
>
> We already have an optional OID system column that can be specified
> during table creation (WITH OIDS). We could have another optional oid
> column (WITH ROW SECURITY) called security_context which would store the
> oid of the role that can see the row; if the oid is zero (InvalidOid),
> anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
> use the oid to look up strings in pg_security.

The above explanation is not correct, as Tom mentioned.
The security system column is declared as TEXT type, however, every tuple
has a Oid value to indicate pg_security system catalog. It enables to
prevent waste of storage. When user tries to read the system column,
it is translated from Oid to text representation.

If the oid is zero, SE-PostgreSQL requires SELinux to provide an alternative
security context called as "unlabeled_t". And SE-PostgreSQL checks client's
right for the tuple which is considered as "unlabeled_t".

The part of implementation is specific for SE-PostgreSQL, so another security
mechanism will able to handle InvalidOid as a mark of "no specific checks".

> Is this something we want for non-SE-PostgreSQL builds? SE-PostgreSQL
> would still be a compile-time option because of all the additional
> SE-Linux support code.

The new system column is now enabled only for SE-PostgreSQL builds.
When we don't enables it, the system column is not appeared and it
does not reuire any additional field in HeapTupleHeader.

We provide it as a common facility for "enhanced" security mechanism.
If the guest of PGACE need the security system column, it has to
define "SECURITY_SYSATTR_NAME" in pg_config.h via configure script.
This constant is the key to activate the security system attribute.

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

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> Here is how I think SQL-level row permissions would work:
>
>> We already have an optional OID system column that can be specified
>> during table creation (WITH OIDS). We could have another optional oid
>> column (WITH ROW SECURITY) called security_context which would store the
>> oid of the role that can see the row; if the oid is zero (InvalidOid),
>> anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
>> use the oid to look up strings in pg_security.
>
> This is just a different syntax for KaiGai's label storage
> implementation. It doesn't really answer any of the hard questions,
> like what the heck is the behavior of foreign keys.

SE-PostgreSQL changes its internal state during foreign key constraint checks.
When user tries to update/delete a PK refered by invisible FK, SE-PostgreSQL
generates an error and prevent inconsistency in FK constraint.
When user tries to insert/update a FK which refers invisible PK, it is failed.
But it does not affect integrity consistency.

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

"Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>> This is just a different syntax for KaiGai's label storage
>> implementation. It doesn't really answer any of the hard questions,
>> like what the heck is the behavior of foreign keys.

> What do you find inadequate about KaiGai's answers to those hard questions?

Mainly just that they're only one set of possible answers. If we're
thinking of baking a particular set of semantics into SQL syntax,
we'd better be darn sure that they are the right semantics --- both
in terms of widest usefulness, and in terms of not being stuck behind
the eight-ball if the SQL standards committee ever moves to standardize
a similar behavior.

Another point is that the proposed behavior leaks quite a lot of
information, since it will fail operations on the basis of tuples that
supposedly aren't visible to the invoking user. While I admit that it's
hard to see an alternative if we're to preserve FK integrity, I have to
worry that this definition isn't going to satisfy the tin-foil-hat
brigade that are supposed to be the main users of SEPostgres. If the
goal is "you don't know the row is there", this doesn't seem to meet it.

I wonder whether it wouldn't make more sense to pursue restrictions
at some different level. SQL already has the concept of REFERENCE
permission, ie, not just anybody can make a foreign key reference to
your table. Maybe there has to be a rule that you can't make an FK
reference to a table you don't have full read permissions for. The
restrictions in the other direction (what can PK table's owner find out
about FK table's contents) are pretty interesting too.

regards, tom lane

Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> Here is how I think SQL-level row permissions would work:
>>> We already have an optional OID system column that can be specified
>>> during table creation (WITH OIDS). We could have another optional oid
>>> column (WITH ROW SECURITY) called security_context which would store the
>>> oid of the role that can see the row; if the oid is zero (InvalidOid),
>>> anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
>>> use the oid to look up strings in pg_security.
>> This is just a different syntax for KaiGai's label storage
>> implementation. It doesn't really answer any of the hard questions,
>> like what the heck is the behavior of foreign keys.
>
> Well, the PGACE documentation says:
>
> http://code.google.com/p/sepgsql/wiki/WhatIsPGACE
>
> Datum pgacePreparePlanCheck(Relation rel)

In the latest patch, this hooks is replaced by pgaceBeginPerformCheckFK()
and pgaceEndPerformCheckFK(), but its purpose is unchanged.

Sorry for the confusable legacy description.

> --> In SE-PostgreSQL case, access controls in tuple level are normally done
> with filtering any violated tuple. However, it can prevent to check
> foreign key constraint, because caller cannot recognize whether no tuple
> refers the primary relation, or any tuple refering are filtered.
> Therefore, SE-PostgreSQL aborts the current transaction if any violated
> tuple refering the primary relation.

Yes, this behavior keeps FK consistency.

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

"Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
> I like the idea of a WITH ROW SECURITY option to enable row-level
> security - that way, tables that don't need it don't have to pay for
> it, but I like the idea of storing a full ACL, as KaiGai proposed,
> rather than just a single role. Seems much more powerful.

... and even more ill-defined.

Consider the following scenario:

1. User alice is a member of role admin.

2. User bob creates a table BT and puts some rows in it that are
supposedly only visible to role admin. He also grants REFERENCE
permission to alice. (Let's suppose he does that directly, not via
the admin role; though the other case is interesting too.)

3. User alice creates a table AT with an FK dependency on BT and then
makes some entries that depend on the only-visible-to-admin rows in BT.
She is allowed to do this, obviously.

4. User charlie revokes alice's membership in admin.

Now what? Alice's FK constraint is violated, according to the rules
KaiGai proposes. Shall REVOKE have to grovel through every table in the
database looking for possible violations ... and of course locking the
entire DB against writes while it does it? That's not gonna fly. I
also note that the failure would expose knowledge of the contents of BT
and AT to charlie, which might not be thought desirable either.

This problem is bad enough if row visibility is defined just by role
membership. I shudder to think of trying to make it a general ACL.

regards, tom lane

Tom Lane wrote:
> 4. User charlie revokes alice's membership in admin.
>
> Now what? Alice's FK constraint is violated, according to the rules
> KaiGai proposes. Shall REVOKE have to grovel through every table in the
> database looking for possible violations ... and of course locking the
> entire DB against writes while it does it? That's not gonna fly. I
> also note that the failure would expose knowledge of the contents of BT
> and AT to charlie, which might not be thought desirable either.

I assume Alice now gets an error on the query that references the
now-invisible foreign key --- that sounds reasonable to me.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
>>> This is just a different syntax for KaiGai's label storage
>>> implementation. It doesn't really answer any of the hard questions,
>>> like what the heck is the behavior of foreign keys.
>
>> What do you find inadequate about KaiGai's answers to those hard questions?
>
> Mainly just that they're only one set of possible answers. If we're
> thinking of baking a particular set of semantics into SQL syntax,
> we'd better be darn sure that they are the right semantics --- both
> in terms of widest usefulness, and in terms of not being stuck behind
> the eight-ball if the SQL standards committee ever moves to standardize
> a similar behavior.

If SQL standard adopts row-level security, it also welcomes for me.
Please note that SE-PostgreSQL works orthogonally from the native
access controls of PostgreSQL.
I think it is usefulness to apply different security policies based on
different rules, architecture and philosophy.

> Another point is that the proposed behavior leaks quite a lot of
> information, since it will fail operations on the basis of tuples that
> supposedly aren't visible to the invoking user. While I admit that it's
> hard to see an alternative if we're to preserve FK integrity, I have to
> worry that this definition isn't going to satisfy the tin-foil-hat
> brigade that are supposed to be the main users of SEPostgres. If the
> goal is "you don't know the row is there", this doesn't seem to meet it.

Yes, it is just a limitation of SE-PostgreSQL's row-level access control.
However, we can avoid actual matter by applying alternative keys for these
kind of databases, as Bruce mentioned before.
No need to say, it is a thing to be described in documentation,
and end-users should make their decison.

One considerable option provided to end-user is to add a switch called as
"boolean" to allow all of row-level access controls.

> I wonder whether it wouldn't make more sense to pursue restrictions
> at some different level. SQL already has the concept of REFERENCE
> permission, ie, not just anybody can make a foreign key reference to
> your table. Maybe there has to be a rule that you can't make an FK
> reference to a table you don't have full read permissions for. The
> restrictions in the other direction (what can PK table's owner find out
> about FK table's contents) are pretty interesting too.

SE-PostgreSQL focuses on the fact client can see the PK refered.
It is different from native SQL's permission, but it think it is just a
difference between security models.

It is worthwhile to achieve secure state of databases in different levels.
For example, privileged database user can override all of access controls.
It is a unignorable risk, as root is considered as a risk in operating
system.

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

>> I like the idea of a WITH ROW SECURITY option to enable row-level
>> security - that way, tables that don't need it don't have to pay for
>> it, but I like the idea of storing a full ACL, as KaiGai proposed,
>> rather than just a single role. Seems much more powerful.
> ... and even more ill-defined.

I agree. We need a better spec for this, starting with a list of
privileges that even make sense. I'm not sure whether it makes sense
to allow anything more than SELECT, UPDATE, an DELETE. INSERT and
TRUNCATE are clearly meaningless. TRIGGER and REFERENCES are
arguable, but I can't imagine a reasonable use case for granting
TRIGGER or REFERENCES on only a subset of the table, so I'm not sure
there's any point in enforcing those on a per-row basis. For an FK,
it might make more sense to simply require REFERENCES permission on
the table and SELECT permission on the referenced tuple (more
generally if I'm going to take a shared lock on a tuple I should need
to have SELECT permission on it).

[snip]

> Now what? Alice's FK constraint is violated, according to the rules
> KaiGai proposes. Shall REVOKE have to grovel through every table in the
> database looking for possible violations ... and of course locking the
> entire DB against writes while it does it? That's not gonna fly. I
> also note that the failure would expose knowledge of the contents of BT
> and AT to charlie, which might not be thought desirable either.

I think you have to resign yourself to the fact that a user who can
see only a subset of the rows in a table may very well see apparent
foreign-key violations. But so what? If the user cares to arrange
things so that this doesn't happen, it is certainly possible. If they
don't, I'm not sure why it's our job to argue with them. Alice's
tuples will still be in the table, and she will see them or not
according to her permissions, and will see the foreign keys they
reference or not according to those permissions.

It's already the case that I can already define a check constraint on
a table that calls a function, insert a bunch of rows into the table,
and then redefine the function to return false for some row that's
already in the table, and voila, my constraint check is violated. It
sucks, but there's a pretty severe performance problem with rechecking
the constraint every time the function is redefined, so we don't.
This can't be any worse, and in fact I don't even think it's as bad.

Random though regarding information leakage: You might be able to find
out something about the hidden portion of a table by using EXPLAIN to
examine the plan for various queries. The stats collector, of course,
will have seen the entire table contents. This might not be a big
deal for basic row-level security (depending on the situation) but it
is more likely to matter for SE-PostgreSQL.

> This problem is bad enough if row visibility is defined just by role
> membership. I shudder to think of trying to make it a general ACL.

If all you store is a role OID, you have no ability to grant
read/write access to only part of a table. That has to be a rather
important use case.

...Robert

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> 4. User charlie revokes alice's membership in admin.
>>
>> Now what? Alice's FK constraint is violated, according to the rules
>> KaiGai proposes. Shall REVOKE have to grovel through every table in the
>> database looking for possible violations ... and of course locking the
>> entire DB against writes while it does it? That's not gonna fly. I
>> also note that the failure would expose knowledge of the contents of BT
>> and AT to charlie, which might not be thought desirable either.

> I assume Alice now gets an error on the query that references the
> now-invisible foreign key --- that sounds reasonable to me.

You mean her data just disappears? Doesn't sound very reasonable to me.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> 4. User charlie revokes alice's membership in admin.
> >>
> >> Now what? Alice's FK constraint is violated, according to the rules
> >> KaiGai proposes. Shall REVOKE have to grovel through every table in the
> >> database looking for possible violations ... and of course locking the
> >> entire DB against writes while it does it? That's not gonna fly. I
> >> also note that the failure would expose knowledge of the contents of BT
> >> and AT to charlie, which might not be thought desirable either.
>
> > I assume Alice now gets an error on the query that references the
> > now-invisible foreign key --- that sounds reasonable to me.
>
> You mean her data just disappears? Doesn't sound very reasonable to me.

Well, she actually gets an error rather than a query with missing data,
which is proabably the best we are going to do, unless we don't
implement row-level security at all.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
> I think you have to resign yourself to the fact that a user who can
> see only a subset of the rows in a table may very well see apparent
> foreign-key violations. But so what?

So you're leaking information about the rows that they're not supposed
to be able to see. This is not what I would call national-security-grade
information hiding --- leastwise *I* certainly wouldn't store nuclear
weapon design information in such a database. The people that the NSA
wants to defend against are more than smart enough, and persistent
enough, to extract information through such loopholes.

I can't escape the lurking suspicion that some bright folk inside the
NSA have spent years thinking about this and have come up with some
reasonably self-consistent definition of row hiding in a SQL database.
But have they published it where we can find it?

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> Tom Lane wrote:
>>> 4. User charlie revokes alice's membership in admin.
>>>
>>> Now what? Alice's FK constraint is violated, according to the rules
>>> KaiGai proposes. Shall REVOKE have to grovel through every table in the
>>> database looking for possible violations ... and of course locking the
>>> entire DB against writes while it does it? That's not gonna fly. I
>>> also note that the failure would expose knowledge of the contents of BT
>>> and AT to charlie, which might not be thought desirable either.
>
>> I assume Alice now gets an error on the query that references the
>> now-invisible foreign key --- that sounds reasonable to me.

In my design, these errors are happen when PK is tries to update or
delete (and kicked trigger functions for FK constraint).
These violated tuples are simply filtered.

> You mean her data just disappears? Doesn't sound very reasonable to me.

In reference cases, we can consider she looks the tables via something
like VIEWs implicitly. The "VIEW" can hide several tuple, but it does
not break any reference consistency in the raw level.

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> You mean her data just disappears? Doesn't sound very reasonable to me.

> Well, she actually gets an error rather than a query with missing data,
> which is proabably the best we are going to do, unless we don't
> implement row-level security at all.

Quite honestly, I think there is no case at all for implementing
row-level security given our current state of knowledge. We have no
idea how to define it in a way that doesn't leak information. And *that
isn't good enough*. The alleged audience for this feature is the type
of spook agency that absolutely will care about that. I do not want to
put in a huge, code-uglifying, expensive-to-maintain patch only to find
that the people who might use it just laugh and say "this is too broken
to consider using". Which I think is precisely what would happen given
the sorts of definitions that are being thrown about here.

This worry is exactly why I asked Josh point-blank whether his
interested government agency had actually studied the proposed patch.
I'd be a lot happier to get a sign-off from some people who knew what
they were doing, even if they wouldn't tell us exactly what the
evaluation critera were. (Hmm, anyone remember the DES controversy?
But so far as I've heard, it appears the NSA were playing it straight
back then.)

regards, tom lane

>> You mean her data just disappears? Doesn't sound very reasonable to me.
>
> In reference cases, we can consider she looks the tables via something
> like VIEWs implicitly. The "VIEW" can hide several tuple, but it does
> not break any reference consistency in the raw level.

I don't understand what this means.

Suppose we have two tables:

CREATE TABLE parent (a integer, primary key (a));
CREATE TABLE child (a integer references parent, b integer);

Consider these queries:

1. SELECT * FROM child
2. SELECT * FROM child JOIN parent ON child.a = parent.a

In query (1), I wouldn't expect the foreign key on child to matter at
all. In query (2), of course, the tuples in parent are no longer
visible, so I expect things to get filtered. I'm not sure whether
this is what you're proposing or not.

...Robert

Robert Haas wrote:
>>> You mean her data just disappears? Doesn't sound very reasonable to me.
>> In reference cases, we can consider she looks the tables via something
>> like VIEWs implicitly. The "VIEW" can hide several tuple, but it does
>> not break any reference consistency in the raw level.
>
> I don't understand what this means.
>
> Suppose we have two tables:

Sorry for lack of explanation.
The idea is similar to several commercial databases with row-level security,
like the Oracle Label Security.

> CREATE TABLE parent (a integer, primary key (a));
> CREATE TABLE child (a integer references parent, b integer);
>
> Consider these queries:
>
> 1. SELECT * FROM child
> 2. SELECT * FROM child JOIN parent ON child.a = parent.a

As an image, the above queries are implicitly translated as follows:

1'. SELECT * FROM child
WHERE i_can_see_tuple(child.security_attribute);
2'. SELECT * FROM child JOIN parent
ON child.a = parent.a
AND i_can_see_tuple(child.security_attribute)
AND i_can_see_tuple(parent.security_attribute);

(*) Please note that rewriting WHERE clause for security purpose is
patented, so SE-PostgreSQL changed its implementation before.
It put a hook on ExecScan() to check visibility of fetched tuple.

> In query (1), I wouldn't expect the foreign key on child to matter at
> all. In query (2), of course, the tuples in parent are no longer
> visible, so I expect things to get filtered. I'm not sure whether
> this is what you're proposing or not.

Yes, it is correct.

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

>> I think you have to resign yourself to the fact that a user who can
>> see only a subset of the rows in a table may very well see apparent
>> foreign-key violations. But so what?
>
> So you're leaking information about the rows that they're not supposed
> to be able to see. This is not what I would call national-security-grade
> information hiding --- leastwise *I* certainly wouldn't store nuclear
> weapon design information in such a database. The people that the NSA
> wants to defend against are more than smart enough, and persistent
> enough, to extract information through such loopholes.

If your plan is to refuse to implement row-level security until
someone produces a design that can never leak information under any
circumstances regardless of how the user configures it, then I
strongly suspect we'll be waiting forever. The designs being put
forward here are capable of being configured in an insecure fashion,
but that's true of any other security mechanism we offer, too.

SE-PostgreSQL needs to be good enough for the NSA, but row-level
security in general does not. Right now, for example, there's no way
to say "I'd like user X to be able to insert rows into this table, and
update and delete the rows they insert, but not update or delete any
rows that don't belong to them" or "I'd like to give user X the
ability to see certain rows in this table, but not all of them." If
the table in question has foreign keys, the database administrator can
make the referenced tables fully visible, or can make sure that the
slices of each table that are visible correspond to one another... or
he can do some crazy, illogical thing that makes no sense and creates
all sorts of apparent referential integrity violations.

But I don't see how any design is going to avoid an administrator
doing crazy, illogical things that make no sense. I'm sure it's
possible to label your SELinux filesystem in a crazy, illogical way,
too.

An orthogonal approach to this problem would be to allow permission
grants that act like a constraint check, rather than applying security
attributes to individual tuples. So for example you could allow
SELECT access to the slice of a table where <some column> = <some
value>. You'd probably want to allow (a) SELECT constraint (must hold
for a tuple to be visible), (b) INSERT constraint (must hold for each
tuple being inserted), (c) BEFORE UPDATE constraint (must hold of each
tuple about to be updated), (d) AFTER UPDATE constraint (must hold of
each new tuple produced by an update), and (e) DELETE constraint (must
hold of each tuple to be deleted). SELECT, BEFORE UPDATE, and DELETE
would silently pass over failing tuples, while INSERT and AFTER UPDATE
would throw an error. I'm sure this wouldn't satisfy the SELinux
folks, but I suspect it has a lot of more mundane applications, and it
avoids the need to store a security attribute on every tuple.

...Robert

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> Tom Lane wrote:
>>> You mean her data just disappears? Doesn't sound very reasonable to me.
>
>> Well, she actually gets an error rather than a query with missing data,
>> which is proabably the best we are going to do, unless we don't
>> implement row-level security at all.
>
> Quite honestly, I think there is no case at all for implementing
> row-level security given our current state of knowledge. We have no
> idea how to define it in a way that doesn't leak information. And *that
> isn't good enough*.

Several prior commercial database management systems give us a hint.

For example, Oracle Label Security can support row-level access
controls, but they does not care such kind of information leaking
called as "covert channel".
It applies an implicit view for row-level access controls, as
I mentioned. (At least, I cannot find a description about PK/FK
constraint in their documentaion with more than 300 pages volume.)

We can think the fact Oracle provides the options shows us there are
unignorable number of people think it is good enough for them.
I think such kind of decision should be made by end-users.
No need to say, I (developer) have to provide well documentation to
shows its specification and *limitation*.
Thus, what Peter said is right. It's also my work.

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

Robert Haas wrote:
>>> I think you have to resign yourself to the fact that a user who can
>>> see only a subset of the rows in a table may very well see apparent
>>> foreign-key violations. But so what?
>> So you're leaking information about the rows that they're not supposed
>> to be able to see. This is not what I would call national-security-grade
>> information hiding --- leastwise *I* certainly wouldn't store nuclear
>> weapon design information in such a database. The people that the NSA
>> wants to defend against are more than smart enough, and persistent
>> enough, to extract information through such loopholes.
>
> If your plan is to refuse to implement row-level security until
> someone produces a design that can never leak information under any
> circumstances regardless of how the user configures it, then I
> strongly suspect we'll be waiting forever. The designs being put
> forward here are capable of being configured in an insecure fashion,
> but that's true of any other security mechanism we offer, too.

In my understanding, security evaluation criteria does not require
to prevent such kind of information leaks (called as illicit information
flow, or covert channel) in all cases.

The ISO/IEC15408 is a set of specifications for security functionalities
of IT products. We can find its requirement about illicit information flow
as follows:

- FDP_IFF.3 Limited illicit information flows, requires the SFP
to cover illicit information flows, but not necessarily
eliminate them.
- FDP_IFF.4 Partial elimination of illicit information flows, requires
the SFP to cover the elimination of some (but not necessarily
all) illicit information flows.
- FDP_IFF.5 No illicit information flows, requires SFP to cover the
elimination of all illicit information flows.

(*) FDP_IFF = Functionalities of Data Protection
Information Flaw control Functions
(*) The larger tail number means more strict requirement.
(*) Common Criteria part.2 at
http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R2.pdf

At least, we can say it is not something like "all or nothing".

> SE-PostgreSQL needs to be good enough for the NSA, but row-level
> security in general does not.

BTW, it seems to me someone misunderstand I works as an agent of NSA.
Is it a humor, itn't it? I've paid my effort to improve the security
of open source software, not for overseas intelligence agency.

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

>> Well, the PGACE documentation says:
>>
>> http://code.google.com/p/sepgsql/wiki/WhatIsPGACE
>>
>> Datum pgacePreparePlanCheck(Relation rel)
>
> In the latest patch, this hooks is replaced by pgaceBeginPerformCheckFK()
> and pgaceEndPerformCheckFK(), but its purpose is unchanged.
>
> Sorry for the confusable legacy description.

I updated it to reflect the latest patches.

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

> > We already have an optional OID system column that can be specified
> > during table creation (WITH OIDS). We could have another optional oid
> > column (WITH ROW SECURITY) called security_context which would store the
> > oid of the role that can see the row; if the oid is zero (InvalidOid),

A role alone is not sufficient. It needs to be the proposed mapping to pg_security.

> > anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
> > use the oid to look up strings in pg_security.
>
> The above explanation is not correct, as Tom mentioned.
> The security system column is declared as TEXT type, however, every tuple
> has a Oid value to indicate pg_security system catalog. It enables to
> prevent waste of storage. When user tries to read the system column,
> it is translated from Oid to text representation.

Imho the important points Bruce wanted to make are:
1. there is only one extra oid storage column per row (regardless whether it is translated to text upon select)
this is already the case in the patch.
2. the column(s) are system columns, so they do not show up in "select *"

I think having access to the oid directly could be beneficial to performance.
e.g. a smart client could cache pg_security and map the oid's to text locally
instead of transferring the quite verbose text representation for every row.
That may be mute, because showing the security_context definitely sounds more
like an admin kind of functionality.
Traditionally the column would probably be oid and sql would need to cast it for
the text representation (e.g. security_context::regsecurity).

Andreas

On Thu, Sep 25, 2008 at 08:57:46PM -0400, Tom Lane wrote:
> Another point is that the proposed behavior leaks quite a lot of
> information, since it will fail operations on the basis of tuples that
> supposedly aren't visible to the invoking user. While I admit that it's
> hard to see an alternative if we're to preserve FK integrity, I have to
> worry that this definition isn't going to satisfy the tin-foil-hat
> brigade that are supposed to be the main users of SEPostgres. If the
> goal is "you don't know the row is there", this doesn't seem to meet it.

The above point, and other similar ones in every discussion of the
proposed functionality, makes me think once again either that the
requirements for this feature aren't understood by everyone, or else
that they're not actually explicit enough. I have a feeling it's the
latter. Certainly, I've not yet read a complete security analysis of
a data system security plan that outlines why the proposed model is
correct.

What I think is really happening with this development is that the
SE-Linux understanding of "security enhancement" has been taken as the
correct analysis for how one secures an information system. That deep
assumption appears to me to be informing much of the development of
SE-PostgreSQL. In particular, that deep assumption includes an
assumption that consistency of access control trumps all. The
Postgres developers who are questioning the SE approach are (I think)
coming at this from the point of view of data systems developers,
where consistency of the data set trumps all.

I suspect that the tension between these approaches will not be
reconciled without a fairly complete outline of possible security
models for data systems, their relationship to what the OS security
people have decided is the right thing to do, and the trade-offs
necessary to make different priorities work. Some of the trade offs
may include things like "violate traditional understanding of data set
consistency" and "possible disclosure of existence of datum". I think
this will be a lot of work, and I'm not volunteering to do it. I
nevertheless think that without it, the SE-PostgreSQL features will
continue to be a very awkward fit.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

On Thu, Sep 25, 2008 at 10:32:24PM -0400, Tom Lane wrote:
> I can't escape the lurking suspicion that some bright folk inside the
> NSA have spent years thinking about this and have come up with some
> reasonably self-consistent definition of row hiding in a SQL database.
> But have they published it where we can find it?

I have a couple contacts in the security world who might be able to
help with references. I'm asking them now.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

Andrew Sullivan <ajs(at)commandprompt(dot)com> writes:
> The above point, and other similar ones in every discussion of the
> proposed functionality, makes me think once again either that the
> requirements for this feature aren't understood by everyone, or else
> that they're not actually explicit enough. I have a feeling it's the
> latter.

Yeah, I think that's exactly the problem here: we've got this large
patch and no agreement on just what requirements it's supposed to meet.
Perhaps others see it differently, but I feel like I'm being told that
whatever the patch does is the right thing by definition ... and yet
it doesn't seem to meet what I would think are the likely requirements
of the users who might actually want such features.

Agreeing on the requirements seems like a necessary condition for
arriving at any consensus on a patch. Where can we get some evidence
that would convince everyone that the requirements for a highly
secure database are X, Y and Z?

regards, tom lane

Zeugswetter Andreas OSB sIT wrote:
>>> anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
>>> use the oid to look up strings in pg_security.
>> The above explanation is not correct, as Tom mentioned.
>> The security system column is declared as TEXT type, however, every tuple
>> has a Oid value to indicate pg_security system catalog. It enables to
>> prevent waste of storage. When user tries to read the system column,
>> it is translated from Oid to text representation.
>
> Imho the important points Bruce wanted to make are:
> 1. there is only one extra oid storage column per row (regardless whether it is translated to text upon select)
> this is already the case in the patch.
> 2. the column(s) are system columns, so they do not show up in "select *"
>
> I think having access to the oid directly could be beneficial to performance.
> e.g. a smart client could cache pg_security and map the oid's to text locally
> instead of transferring the quite verbose text representation for every row.
> That may be mute, because showing the security_context definitely sounds more
> like an admin kind of functionality.
> Traditionally the column would probably be oid and sql would need to cast it for
> the text representation (e.g. security_context::regsecurity).

In most of cases, SE-PostgreSQL does not need to translate the security identifier
into text representation, because it caches the result of access checks between
the client and the recently used "security_context". SE-PostgreSQL can make its
decision refering the internal hash table with the security Oid.
(See, src/backend/security/sepgsql/avc.c)

When user requires to expose "security_context", it is necessary to lookup pg_security
to translate the security Oid into text representation, but I guess it is not frequently.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Dear colleagues,

I said earlier I'd ask around about some of the literature on security
controls vs. databse accessibility and side channels. I did, and I
heard back.

One person told me that this conference often has things on this
topic:

http://www.ieee-security.org/TC/SP-Index.html

From my brief glimpse of the TOCs from the proceedings, as well as
some spelunking in the ACM guide, it seems to me that some people have
already worked out what ought to happen in many of these cases, and
all we need to do is write down what we think ought to happen for the
various use cases. I note in particular that an awful lot of work
seems to be coming out of the health care sector in this area. That
strikes me as at least as good a guide as national security concerns,
and anything that one might want to do probably ought to be able to
cope with at least those two caricatures of use cases.

I also found a 2007 doctoral thesis by Azhar Rauf, Colorado Technical
University, _A tradeoff analysis between data accessibility and
inference control for row, column, and cell level security in
relational databases_. The title and abstract make me think it might
be worth looking at.

Hope this is helpful,

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

KaiGai Kohei wrote:
> > SE-PostgreSQL needs to be good enough for the NSA, but row-level
> > security in general does not.
>
> BTW, it seems to me someone misunderstand I works as an agent of NSA.
> Is it a humor, itn't it? I've paid my effort to improve the security
> of open source software, not for overseas intelligence agency.

The comment was not directed at you. The comment was that SE-Linux was
perhaps designed by the NSA, so an implementation matching SE-Linux will
be good enough for the NSA. The comment goes on to say that we might
want something better or more consistent than the NSA requirements.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
> > I think you have to resign yourself to the fact that a user who can
> > see only a subset of the rows in a table may very well see apparent
> > foreign-key violations. But so what?
>
> So you're leaking information about the rows that they're not supposed
> to be able to see. This is not what I would call national-security-grade
> information hiding --- leastwise *I* certainly wouldn't store nuclear
> weapon design information in such a database. The people that the NSA
> wants to defend against are more than smart enough, and persistent
> enough, to extract information through such loopholes.
>
> I can't escape the lurking suspicion that some bright folk inside the
> NSA have spent years thinking about this and have come up with some
> reasonably self-consistent definition of row hiding in a SQL database.
> But have they published it where we can find it?

I am confused how knowing that a sequence number used for a primary key
exists or doesn't exist is leaking _meaningful_ information. People
might know the sequence number exists, but how is that information
useful. Now, if natural keys are used, that is a different story.

I am, of course, supportive of digging deeper to find the best possible
behavior. I am also supportive of making row-level security an
SQL-level feature that can be used beyond SE-Linux, and will allow the
feature to be tested on all platforms.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> I am confused how knowing that a sequence number used for a primary key
> exists or doesn't exist is leaking _meaningful_ information. People
> might know the sequence number exists, but how is that information
> useful. Now, if natural keys are used, that is a different story.

Right. It might be that securing a database requires not just some
security mechanisms but also some database design rules (like "don't
allow foreign keys except on synthetic IDs"). But it seems to me that
we are just flailing around in the dark because we don't have that
bigger picture of how the features would actually get used.

The literature pointers that Andrew just gave us seem promising to me.
Who's going to go searching for some useful info?

regards, tom lane

> The literature pointers that Andrew just gave us seem promising to me.
> Who's going to go searching for some useful info?

I couldn't find much on the pages linked directly from the link Andrew
sent, but a Google search for "site:ieee-security.org database" turned
up the following:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.2185
A MAC policy framework for multilevel relational databases
by Xiaolei Qian, Teresa F. Lunt

I haven't read through this in detail yet, but appears to be highly
relevant to Tom's concerns about referential integrity.

...Robert

On Fri, Sep 26, 2008 at 06:15:46PM -0400, Bruce Momjian wrote:

> I am confused how knowing that a sequence number used for a primary key
> exists or doesn't exist is leaking _meaningful_ information.

This sort of side-channel intelligence is _exactly_ how certain kinds
of security exploits work: I'm not supposed to know that _x_ exists;
but by knowing key-of-_x_, I learn that _x_ exists. From existence, I
can infer something, and from that inference I construct an attack
that was supposed to be forestalled by the access controls.

I am by no means a security expert, but I know enough about the area
to know that it is very hard to get right, and that seemingly
insignificant flaws in design turn out to be major vulnerabilities.
To speak about something I do know about, when DNS was designed,
nobody could have imagined that the widespread availability of
recursion would turn out to be a flaw. Today, it turns out that open
recursion can be used in an attack that magnifies the attacker's
outbound traffic by many orders of magnitude. This sort of surprise
side effect is why I am so anxious that something advertised as a
security system fit really well with the proposed use cases.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I am confused how knowing that a sequence number used for a primary key
> > exists or doesn't exist is leaking _meaningful_ information. People
> > might know the sequence number exists, but how is that information
> > useful. Now, if natural keys are used, that is a different story.
>
> Right. It might be that securing a database requires not just some
> security mechanisms but also some database design rules (like "don't
> allow foreign keys except on synthetic IDs"). But it seems to me that
> we are just flailing around in the dark because we don't have that
> bigger picture of how the features would actually get used.
>
> The literature pointers that Andrew just gave us seem promising to me.
> Who's going to go searching for some useful info?

I found this paper from 1996:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950

Full PDF at link in right column. The interesting chapters are chapter
3, that talks about "ENTITY AND REFERENTIAL INTEGRITY IN MLS DATABASES"
and chapter 4, "COVERT CHANNELS". It mentions "polyinstantiation":

These security considerations have led to the notion of
polyinstantiation [Denning 87]. Polyinstantiation forces a relation to
contain multiple tuples with the same primary key but distinguishable by
their classification levels or by the non-primary key attributes of the
relation [Lunt 91].

which I think we want to avoid. It also talks about cases where the
primary and foreign key rows have identical or different security
settings. It talks about "COVERT CHANNELS", which is information
leaking.

And it mentions TCSEC (Trusted Computer System Evaluation Criteria):

http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria

which I think is the proper term for the security target we are trying
to address, or at least one of the targets.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> Andrew Sullivan <ajs(at)commandprompt(dot)com> writes:
>> The above point, and other similar ones in every discussion of the
>> proposed functionality, makes me think once again either that the
>> requirements for this feature aren't understood by everyone, or else
>> that they're not actually explicit enough. I have a feeling it's the
>> latter.
>
> Yeah, I think that's exactly the problem here: we've got this large
> patch and no agreement on just what requirements it's supposed to meet.
> Perhaps others see it differently, but I feel like I'm being told that
> whatever the patch does is the right thing by definition ... and yet
> it doesn't seem to meet what I would think are the likely requirements
> of the users who might actually want such features.

Indeed, I might not say my motivation and the goal/target of SE-PostgreSQL
in explicit.

As I repeated several times, SE-PostgreSQL applies the seuciry policy
of SELinux to achieve consistency in access controls. This feature
enables to restrict client's privileges on accesses to database objects,
as if it accesses to filesystem objects. Its background is our nightmare
for web application flaws.

The major purpose of this feature is to provide the most important
component to run enterprise class web application with least privilege
set which is consistent at whole of the system.
I know there are various aspect of opinions for SELinux, but it has
succeeded to run server applications with the least privileges and
enabled to prevent attachs from malicious ones.
However, web application had some of characteristics different from
server application.

The LAPP software stack is very popular architecture to provide web
services, and widely accepted. I had a concern from the viewpoint of
security folks. The LAPP stack is constructed from four components,
and each of them provides individual security mechanism.
For example, OS(Linux) provides filesystem permission and SELinux,
RDBMS(PostgreSQL) provides database ACL, and so on.
In addition, most of web application stores its data into databases
not only filesystems. This fact prevented to work web application
with least privilege set, because in-kernel SELinux cannot trap
accesses on database objects. In this situation, we have to set up
database acl, and choose a proper database role.
But there is no explicit relationship between database roles and
the least privilege set (called as security context), so web
application can/must select arbitrary one.

In my vision, Apache assigns its contents handler an individual
security context based on HTTP authentication, source IP address
and so on just before web application invoked.
Because web applications works with individual least privilege set,
its accesses on filesystem are restricted by the security policy.
In a similar way, its accesses on databases are also restricted
via SE-PostgreSQL by same policy, by same privilege set.
(Please note that SE-PostgreSQL obtain the security context of
peer process using getpeercon() API provided by SELinux.)
This architecture enables to minimize security sensitive code,
like openning database connection.
If we adopt this approach, web application can also select
a database role, but the outline of its privileges are defined
by security policy.

In recent years, web application flaws are nightmare for us.
The recent report said 95% of significant incidents on the first
half of 2008, and 75% of them were SQL injection in Japan.
My ultimate goal is to help the situation with mandatory access
control and least priviled set for whole of LAPP stack.

The fine-grained access controls are provided for practical advantage.
One requirement I got is to apply SE-PostgreSQL as a backend of medical
information system which is shared by several small hospitals.
An electronic chart has common format, so it is simple design to store
it within a single table. And, individual tuples have individual access
right which is only exposed to his doctor and medical staffs.

The actual origin of fine-grained access control is sense of rivalry
towards the prior commercial security aware RDBMS (like Oracle Label
Security, IBM DB2), however, it is neccesary to utilize access controls.
If we don't have fine-grained controls, any web application have to have
privileges to access all charts of patients, and vulnerable for SQL
injection. It is a real practical advantage, I think.

Sorry for long my description.

Thanks,

> Agreeing on the requirements seems like a necessary condition for
> arriving at any consensus on a patch. Where can we get some evidence
> that would convince everyone that the requirements for a highly
> secure database are X, Y and Z?
>
> regards, tom lane
>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> I am confused how knowing that a sequence number used for a primary key
>>> exists or doesn't exist is leaking _meaningful_ information. People
>>> might know the sequence number exists, but how is that information
>>> useful. Now, if natural keys are used, that is a different story.
>> Right. It might be that securing a database requires not just some
>> security mechanisms but also some database design rules (like "don't
>> allow foreign keys except on synthetic IDs"). But it seems to me that
>> we are just flailing around in the dark because we don't have that
>> bigger picture of how the features would actually get used.
>>
>> The literature pointers that Andrew just gave us seem promising to me.
>> Who's going to go searching for some useful info?
>
> I found this paper from 1996:
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950
>
> Full PDF at link in right column. The interesting chapters are chapter
> 3, that talks about "ENTITY AND REFERENTIAL INTEGRITY IN MLS DATABASES"
> and chapter 4, "COVERT CHANNELS". It mentions "polyinstantiation":
>
> These security considerations have led to the notion of
> polyinstantiation [Denning 87]. Polyinstantiation forces a relation to
> contain multiple tuples with the same primary key but distinguishable by
> their classification levels or by the non-primary key attributes of the
> relation [Lunt 91].
>
> which I think we want to avoid.

At the past, I had considered to implement polyinstantiated table
as a part of SE-PostgreSQL, but it required us unacceptable scale
of changes, so I dropped the idea.

> It also talks about cases where the
> primary and foreign key rows have identical or different security
> settings. It talks about "COVERT CHANNELS", which is information
> leaking.
>
> And it mentions TCSEC (Trusted Computer System Evaluation Criteria):
>
> http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria
>
> which I think is the proper term for the security target we are trying
> to address, or at least one of the targets.

Yes, TCSEC gives us structured requirement sets categorized into several
security levels.

I introduced a requirement of ISO/IEC15408 in the previous message.
It is a more modern security evaluation criteria, and designed based
on the TCSEC from a historical angle.
So, they have similar requirements.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

KaiGai Kohei wrote:
> As I repeated several times, SE-PostgreSQL applies the seuciry policy
> of SELinux to achieve consistency in access controls. This feature
> enables to restrict client's privileges on accesses to database objects,
> as if it accesses to filesystem objects. Its background is our nightmare
> for web application flaws.
>
> The major purpose of this feature is to provide the most important
> component to run enterprise class web application with least privilege
> set which is consistent at whole of the system.

How important is this consistency goal in reality? We typically
recommend that database applications run entirely in the database, for
transaction integrity reasons and so on. Unless you are doing wild and
fun things with server-side copy or untrusted procedural languages,
there really shouldn't be that much use for consistency of access
control between PostgreSQL and something else. In fact, on top of the
transactional integrity criterion, having consistent access control is
one of the reasons to have all your production data in the database
system and nowhere else.

Of coure, this is an ideal state, and we all of to break that once in a
while. But hence the honest question, how often does that really happen
and to what extent, and does that justify the significant investment
that is being proposed here?

> In recent years, web application flaws are nightmare for us.
> The recent report said 95% of significant incidents on the first
> half of 2008, and 75% of them were SQL injection in Japan.
> My ultimate goal is to help the situation with mandatory access
> control and least priviled set for whole of LAPP stack.

As I had previously mentioned, we have to distinguish these two goals:
consistent access controls and mandatory access controls.

Then, how does MAC help with SQL injections? Using the existing
role-based system you can already define least-privilege users that are
essentially powerless even if SQL injections were to happen. I am not
aware that important flaws or gaps in our role-based access control
system have been pointed out that would make it impossible to create
applications with security levels similar to those achievable with a MAC
system.

Now, if you come back to your original goal of consistency in access
control, then it may in fact turn out that an
FLASK/SELinux/SE-PostgreSQL-based system is the best common ground for
such a system, but I am unconvinced that MAC by itself is necessary.

Peter,

> How important is this consistency goal in reality?

It's actually the primary point of SE-Linux. Its audience wants a
centralized policy manager which applies access policies to everything
on the network, regardless of whether it's a file, a port, or a database.

Oracle has not been consistent, and as a result the security geeks have
been very frustrated with Oracle.

--Josh

Peter Eisentraut wrote:
> > The major purpose of this feature is to provide the most important
> > component to run enterprise class web application with least privilege
> > set which is consistent at whole of the system.
>
> How important is this consistency goal in reality? We typically
> recommend that database applications run entirely in the database, for
> transaction integrity reasons and so on. Unless you are doing wild and
> fun things with server-side copy or untrusted procedural languages,
> there really shouldn't be that much use for consistency of access
> control between PostgreSQL and something else. In fact, on top of the
> transactional integrity criterion, having consistent access control is
> one of the reasons to have all your production data in the database
> system and nowhere else.
>
> Of coure, this is an ideal state, and we all of to break that once in a
> while. But hence the honest question, how often does that really happen
> and to what extent, and does that justify the significant investment
> that is being proposed here?

> Then, how does MAC help with SQL injections? Using the existing
> role-based system you can already define least-privilege users that are
> essentially powerless even if SQL injections were to happen. I am not
> aware that important flaws or gaps in our role-based access control
> system have been pointed out that would make it impossible to create
> applications with security levels similar to those achievable with a MAC
> system.

I think there are two goals here. At the SQL-level, we will have
per-role row and column permissions (which seem valuable on their own),
and SE-PostgreSQL allows those permissions to be controlled at the
operating system level rather than at the database level.

I think your major question is how often do you have users that you need
to control at both the SQL _and_ operating system level. I guess the
answer is that security policy suggests controlling things at the lowest
level, and bubling that security up into the database and applications.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

> At the past, I had considered to implement polyinstantiated table
> as a part of SE-PostgreSQL, but it required us unacceptable scale
> of changes, so I dropped the idea.

The TrustedSolaris folks would like polyinstantiation, but I don't know
if they actually have anyone working on Postgres anymore.

--Josh

Josh Berkus wrote:
>
> > At the past, I had considered to implement polyinstantiated table
> > as a part of SE-PostgreSQL, but it required us unacceptable scale
> > of changes, so I dropped the idea.
>
> The TrustedSolaris folks would like polyinstantiation, but I don't know
> if they actually have anyone working on Postgres anymore.

I think polyinstantiation is an issue that will need much more research
before deciding on impelemeting it.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Peter Eisentraut wrote:
> KaiGai Kohei wrote:
>> As I repeated several times, SE-PostgreSQL applies the seuciry policy
>> of SELinux to achieve consistency in access controls. This feature
>> enables to restrict client's privileges on accesses to database objects,
>> as if it accesses to filesystem objects. Its background is our nightmare
>> for web application flaws.
>>
>> The major purpose of this feature is to provide the most important
>> component to run enterprise class web application with least privilege
>> set which is consistent at whole of the system.
>
> How important is this consistency goal in reality? We typically
> recommend that database applications run entirely in the database, for
> transaction integrity reasons and so on.

It is a bit pointless.
The "consistency" in this term is also applied to references to static
web contents, like Jpeg images, PDF documents and so on.
These are not accessed via web application and databases because httpd
makes a response directly, but most of web applications are constructed
with dynamic and static contents.

Have you seen the example?
http://kaigai.myhome.cx/index.php (id: foo/var/baz pass: sepgsql)

It returns different query result based on the security context associated
with HTTP authenticated user. In like wise, your accesses to the listed
three Jpeg files are also restricted.
In both cases, a user "foo" cannot access anything except for objects
labeled as "FooData" or unlabled.

> Of coure, this is an ideal state, and we all of to break that once in a
> while. But hence the honest question, how often does that really happen
> and to what extent, and does that justify the significant investment
> that is being proposed here?

I think it is very usual case.
For example, it is a usefull case for a web-based document management
system to apply consistent access control policy for database tuples
and pdf documents on filesystem.

> Then, how does MAC help with SQL injections? Using the existing
> role-based system you can already define least-privilege users that are
> essentially powerless even if SQL injections were to happen. I am not
> aware that important flaws or gaps in our role-based access control
> system have been pointed out that would make it impossible to create
> applications with security levels similar to those achievable with a MAC
> system.

This feature is mainly placed on fine-grained access controls.
If 50% of tuples are invisible, the scope of dameges are limited.
However, please consider a case when connection string is hijacked
and malicious SQL is injected. As widely known, it is almost impossible
to eliminate all bugs withing various kind of web applications.

> Now, if you come back to your original goal of consistency in access
> control, then it may in fact turn out that an
> FLASK/SELinux/SE-PostgreSQL-based system is the best common ground for
> such a system, but I am unconvinced that MAC by itself is necessary.

It's unclear for me the meanings of "MAC by itself".
Are you wondering the mandatory access control policy by SE-PostgreSQL, not
a Linux kernel?

If so, please consider the relationship between a client, an object manager
and method to access.
In operating system case, a client (process) invokes a system call to access
filesystem object which is managed by operating system. It is similar to that
a client send a SQL query to access database object which is managed by database
management system.
# Accesses to database objects are invisible for operating system, at all. :)

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

Bruce Momjian wrote:
> I think there are two goals here. At the SQL-level, we will have
> per-role row and column permissions (which seem valuable on their own),
> and SE-PostgreSQL allows those permissions to be controlled at the
> operating system level rather than at the database level.

Yes, it is correct.
As someone noted, SQL-level fine-grained access controls are also usefull
feature. I understand it.
SE-PostgreSQL makes its decision based on the security policy stored
in operating system because of the "consistency". However, database objects
are invisible for operating system, so we have to add an option to RDBMS.

> I think your major question is how often do you have users that you need
> to control at both the SQL _and_ operating system level. I guess the
> answer is that security policy suggests controlling things at the lowest
> level, and bubling that security up into the database and applications.

As I mentioned at the previous message, it is very frequent case when
a single web application accesses both filesystem objects and database
objects at the same time.
The important thing is to turn off at the main. Smaller number of security
sensitive codes are betther for consistency and completeness in security.

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

Bruce Momjian wrote:
> Josh Berkus wrote:
>>> At the past, I had considered to implement polyinstantiated table
>>> as a part of SE-PostgreSQL, but it required us unacceptable scale
>>> of changes, so I dropped the idea.
>> The TrustedSolaris folks would like polyinstantiation, but I don't know
>> if they actually have anyone working on Postgres anymore.
>
> I think polyinstantiation is an issue that will need much more research
> before deciding on impelemeting it.

As of this April, they didn't have a plan to implement polyinstantiation
at the row-level, but considered it in per-table granularity.
Of course, they also understood row-level polyinstantiation is a tough work.

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

> Have you seen the example?
> http://kaigai.myhome.cx/index.php (id: foo/var/baz pass: sepgsql)
^^^^^^^^^^^^^^^^^^^^^^^^^
It means we can select one of "foo", "var" or "baz", and they have same
password. I'm sorry, if it was a confusable representation.

> It returns different query result based on the security context associated
> with HTTP authenticated user. In like wise, your accesses to the listed
> three Jpeg files are also restricted.
> In both cases, a user "foo" cannot access anything except for objects
> labeled as "FooData" or unlabled.
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

I updated the following SE-PostgreSQL patches:

[1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1076.patch
[2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1076.patch
[3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1076.patch
[4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1076.patch
[5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1076.patch

- Patches are rebased to the latest CVS HEAD.
- Improvement of performance penalty for access checks.
Reworks in access vector chache enables to reduce performance loss, as follows:
http://kaigai.sakura.ne.jp/sblo_files/kaigai/image/080930_sepgsql_performance.png
It shows about 8% loss in maximum, and larger scale database give us
smaller losses in trend.
- Add a hook to check permission on "COPY TO/FROM <file>".
In the previous version, SE-PostgreSQL does not check permissions
to the file used in COPY statement. It is fixed.
- Documentation updates
- Descriptions for build & install are reworked, because most of
security policy for SE-PostgreSQL now got merged into the upstream
selinux-policy package.
- Add a "Limitation" section to describe about covert channel and
reference integrity.

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

Now we have just a month due to the final deadline.

I think we could sort out and make clear its conceptual issues
during CommitFest:Sep. So, I think it is good time that we can
move to the disucussion about its implementation.

Anyway, I want any suggestions what should I pay my efforts to
during the remaining month.

Thanks,

KaiGai Kohei wrote:
> I updated the following SE-PostgreSQL patches:
>
> [1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1076.patch
> [2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1076.patch
> [3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1076.patch
> [4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1076.patch
> [5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1076.patch
>
> - Patches are rebased to the latest CVS HEAD.
> - Improvement of performance penalty for access checks.
> Reworks in access vector chache enables to reduce performance loss, as
> follows:
>
> http://kaigai.sakura.ne.jp/sblo_files/kaigai/image/080930_sepgsql_performance.png
>
> It shows about 8% loss in maximum, and larger scale database give us
> smaller losses in trend.
> - Add a hook to check permission on "COPY TO/FROM <file>".
> In the previous version, SE-PostgreSQL does not check permissions
> to the file used in COPY statement. It is fixed.
> - Documentation updates
> - Descriptions for build & install are reworked, because most of
> security policy for SE-PostgreSQL now got merged into the upstream
> selinux-policy package.
> - Add a "Limitation" section to describe about covert channel and
> reference integrity.
>
> Thanks,

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

The latest version of SE-PostgreSQL patches are here:

[1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1081.patch
[2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1081.patch
[3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1081.patch
[4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1081.patch
[5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1081.patch

Updates:
- Permission checks were added for objects within "WITH RECURSIVE" clause.
- New SE-PostgreSQL testcases were added.

As I mentioned before, currently I want any suggestion to go forward
the reviewing process of SE-PostgreSQL, but it is unclear for me.
What should I do during the remaining 25 days?

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

KaiGai Kohei wrote:
> Bruce Momjian wrote:
>>> > 2) Do we want row-level permissions at the SQL level?
>>>
>>> Now I'm working for it and will submit patches due to the end of Oct,
>>> if it is really required to make progress reviewing of SE-PostgreSQL
>>> on the v8.4 development cycle.
>>> However, the scale of its demand is unclear for me.
>>
>> Yes, which is why I would like the community to answer the question
>> before you have to start coding things. I will say that if we do want
>> it, the SE-Linux code will be 96% in separate modules and will make it
>> much easier to accept.
>
> OK, I'll stop my hand today, and wait for pgsql-hacker's opinions.

I want to confirm the conclusion of this issue.

If I can understand correctly, we don't have a clear conclusion of this.
So, it is unclear for me whether the row-level permission at SQL level is
necessary to progress the reviewing process of SE-PostgreSQL, or not.

Please give me any suggestion.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

KaiGai,

> If I can understand correctly, we don't have a clear conclusion of this.
> So, it is unclear for me whether the row-level permission at SQL level
> is necessary to progress the reviewing process of SE-PostgreSQL, or not.

Can you *do* the row-level permission?

--
--Josh

Josh Berkus
PostgreSQL
San Francisco

Josh Berkus wrote:
> KaiGai,
>
>> If I can understand correctly, we don't have a clear conclusion of this.
>> So, it is unclear for me whether the row-level permission at SQL level
>> is necessary to progress the reviewing process of SE-PostgreSQL, or not.
>
> Can you *do* the row-level permission?

I think it is a tough work to complete within three weeks.

I may be able to make a patch, but I guess its qualities (number of bugs,
documentation, test cases and so on) are far from SE-PostgreSQL level.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

> Can you *do* the row-level permission?

I don't think there's any consensus on a design.

Getting consensus on a design seems to actually be one of the harder
aspects of PostgreSQL development. The pattern seems to be:

1. Someone submits a patch. By definition, the patch embodies some
particular design.
2. One or more members of core express concerns about the design
embodied in the patch.
3. If the concerns are fairly specific and not mutually contradictory,
the submitter revises the patch accordingly and it gets committed
(hopefully without having to discard too much of their previous work).
4. If the concerns are fairly vague and open-ended, or if they
contract each other, the patch hovers in limbo for eternity.

I'm not sure what the solution to this problem is. The fact that a
member of core does not like a particular design for feature X does
not oblige that person to produce a better one, but it's pretty tough
to proceed without it.

In the case of SE-PostgreSQL, two members of core expressed concerns:

- Peter Eisentraut expressed concern about implementing row-level
security via SE-PostgreSQL without first implementing some sort of
SQL-based row-level security. KaiGai expressed willingness to
implement that, but we still don't have a design, so I assume KaiGai
is going to implement... something... and hope that it turns out to be
acceptable.

- Tom Lane expressed concerns about covert channels to which KaiGai
responded, AIUI, that the patch was pretty useful even without
addressing that issue, but if Tom isn't willing to see the patch
committed otherwise, then KaiGai has to decide between giving up and
attempting to implement some form of polyinstantiation - which will
not be easy, and which is far from guaranteed to be accepted if he
does develop it.

In both cases, the lack of a clear roadmap means that a dedicated
developer is potentially putting in a lot of time and effort
developing what may end up being a complete dead-end.

...Robert

Robert Haas wrote:
>> Can you *do* the row-level permission?
>
> I don't think there's any consensus on a design.

Yes, unfortunatelly.
No one replied to my proposed design:
http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2

> Getting consensus on a design seems to actually be one of the harder
> aspects of PostgreSQL development. The pattern seems to be:
>
> 1. Someone submits a patch. By definition, the patch embodies some
> particular design.
> 2. One or more members of core express concerns about the design
> embodied in the patch.
> 3. If the concerns are fairly specific and not mutually contradictory,
> the submitter revises the patch accordingly and it gets committed
> (hopefully without having to discard too much of their previous work).
> 4. If the concerns are fairly vague and open-ended, or if they
> contract each other, the patch hovers in limbo for eternity.
>
> I'm not sure what the solution to this problem is. The fact that a
> member of core does not like a particular design for feature X does
> not oblige that person to produce a better one, but it's pretty tough
> to proceed without it.

Yes, I have had similar experiences in Linux kernel development for
several years.
The amount of time to get consensus is one of the reason why I want
to move the SQL based row-level security to v8.5 development cycle.

> In the case of SE-PostgreSQL, two members of core expressed concerns:
>
> - Peter Eisentraut expressed concern about implementing row-level
> security via SE-PostgreSQL without first implementing some sort of
> SQL-based row-level security. KaiGai expressed willingness to
> implement that, but we still don't have a design, so I assume KaiGai
> is going to implement... something... and hope that it turns out to be
> acceptable.

Its conclusion is actually not clear for me.
The proposed SQL based row-level security assumes what he pointed out
is right, but I don't know the reason why it should be placed prior.

I guess he intend to share the code for row-level security, thus it
should be implemented prior to the OS specific feature. But most of
SE-PostgreSQL code is separated from core implementation and invoked
via security hooks, so it is unsuitable to share code with other
facilities.

In my preference, I want to pay my efforts for OS-independent row-level
security in the v8.5 cycle with enough days, and want to concentrate for
SE-PostgreSQL in the v8.4 cycle, as I mentioned before.
But I will do, if it is unacceptable.

> - Tom Lane expressed concerns about covert channels to which KaiGai
> responded, AIUI, that the patch was pretty useful even without
> addressing that issue, but if Tom isn't willing to see the patch
> committed otherwise, then KaiGai has to decide between giving up and
> attempting to implement some form of polyinstantiation - which will
> not be easy, and which is far from guaranteed to be accepted if he
> does develop it.

Its conclusion it not clear.

I think the polyinstantiation is too much requirements, as prior major
commercial RDBMS with row-level security (like Oracle Label Security)
does not care about such kind of covert channels.
It is quite natural to describe such kind of limitation/specification
on the documentation explicitly to help end-user's decision.

> In both cases, the lack of a clear roadmap means that a dedicated
> developer is potentially putting in a lot of time and effort
> developing what may end up being a complete dead-end.

I believe such a situation will help nobody get happy.

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

KaiGai Kohei wrote:
> Robert Haas wrote:
> >> Can you *do* the row-level permission?
> >
> > I don't think there's any consensus on a design.
>
> Yes, unfortunatelly.
> No one replied to my proposed design:
> http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2

Yes, we got stuck on the covert channels issue. Frankly I think the use
of non-natural keys addresses most of the covert channel issues and
should be recommended for secure setups --- I don't think we are going to
do any better than that and think we need to move forward on that
assumption. We can cite
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950, which
outlines the security risks.

> > Getting consensus on a design seems to actually be one of the harder
> > aspects of PostgreSQL development. The pattern seems to be:
> >
> > 1. Someone submits a patch. By definition, the patch embodies some
> > particular design.
> > 2. One or more members of core express concerns about the design
> > embodied in the patch.
> > 3. If the concerns are fairly specific and not mutually contradictory,
> > the submitter revises the patch accordingly and it gets committed
> > (hopefully without having to discard too much of their previous work).
> > 4. If the concerns are fairly vague and open-ended, or if they
> > contract each other, the patch hovers in limbo for eternity.
> >
> > I'm not sure what the solution to this problem is. The fact that a
> > member of core does not like a particular design for feature X does
> > not oblige that person to produce a better one, but it's pretty tough
> > to proceed without it.

Yes, see above --- I think it is time to move forward.

> Yes, I have had similar experiences in Linux kernel development for
> several years.
> The amount of time to get consensus is one of the reason why I want
> to move the SQL based row-level security to v8.5 development cycle.

As I stated before, I think doing an SE-Linux version and then adding a
more generalized solution is doing things in the wrong order because
the generalized solution is going to have to re-do the SE-Linux stuff.
As much as I would like to see SE-Linux support in 8.4, I think we need
general column and row-level permission built with an eye on what
SE-Linux will need, then add SE-Linux security.

> > In the case of SE-PostgreSQL, two members of core expressed concerns:
> >
> > - Peter Eisentraut expressed concern about implementing row-level
> > security via SE-PostgreSQL without first implementing some sort of
> > SQL-based row-level security. KaiGai expressed willingness to
> > implement that, but we still don't have a design, so I assume KaiGai
> > is going to implement... something... and hope that it turns out to be
> > acceptable.
>
> Its conclusion is actually not clear for me.
> The proposed SQL based row-level security assumes what he pointed out
> is right, but I don't know the reason why it should be placed prior.
>
> I guess he intend to share the code for row-level security, thus it
> should be implemented prior to the OS specific feature. But most of
> SE-PostgreSQL code is separated from core implementation and invoked
> via security hooks, so it is unsuitable to share code with other
> facilities.

You are right based on line counts in the patch, but based on actual
changes to the existing code, SE-Linux changes very much match what
SQL-level permissions would need.

> > - Tom Lane expressed concerns about covert channels to which KaiGai
> > responded, AIUI, that the patch was pretty useful even without
> > addressing that issue, but if Tom isn't willing to see the patch
> > committed otherwise, then KaiGai has to decide between giving up and
> > attempting to implement some form of polyinstantiation - which will
> > not be easy, and which is far from guaranteed to be accepted if he
> > does develop it.
>
> Its conclusion it not clear.
>
> I think the polyinstantiation is too much requirements, as prior major

Agreed on polyinstantiation.

> commercial RDBMS with row-level security (like Oracle Label Security)
> does not care about such kind of covert channels.
> It is quite natural to describe such kind of limitation/specification
> on the documentation explicitly to help end-user's decision.

Agreed.

> > In both cases, the lack of a clear roadmap means that a dedicated
> > developer is potentially putting in a lot of time and effort
> > developing what may end up being a complete dead-end.
>
> I believe such a situation will help nobody get happy.

I think we need to see a specification on how SQL-level row permissions
would work, and get column-level permissions into CVS.

To summarize, 70% of the SE-Linux patch is in stand-alone C files, which
has little disruption, but 30% are changes to the core backend code,
which will be disruptive, so we would like to have SQL-level permissions
that everyone uses to be that disruption, and have SE-Linux attach to
those capabilities.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> To summarize, 70% of the SE-Linux patch is in stand-alone C files, which
> has little disruption, but 30% are changes to the core backend code,
> which will be disruptive, so we would like to have SQL-level permissions
> that everyone uses to be that disruption, and have SE-Linux attach to
> those capabilities.

Another reason for this ordering is that backend coders need to make
sure your backend changes remain working as they change other things.
If the code is mostly SQL-level, anyone case test it but if it is tied
to SE-Linux it is hard for non-SE-Linux people to test.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Mon, 2008-10-06 at 17:25 +0900, KaiGai Kohei wrote:

> What should I do during the remaining 25 days?

I haven't been following this much, but I note that there is lots of
confusion over the international standards, guidelines, recommendations,
specifications etc that we should be following. AFAICS the requirements
have not been solidified and so there is little scope for examining the
patch to see if it meets any particular definition of usable.

It would be very useful to write a long Wiki article explaining what
standards you think the security community want and how those have been
implemented in your patches. And also ones they don't want and why.
Maybe you have all that already, so its just a case of exposing it.

If it is clearly written and easily publicly accessible (no patches
etc), then we can easily forward these links to people in the right
communities and they can provide feedback. I will forward to my UK Gov
contacts if you post a link (and to me, cos I'm not reading these
threads). Do it soon, please.

Once that's done, it can then be used as an info source for interested
people once the patch has been accepted, so it will be valuable over
time.

There's a clear need for Postgres in government and hi-security
businesses, so we need to get this right. But there's not much point
doing 65% or 135% of what's needed.

Your efforts and attention are appreciated by all.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Bruce Momjian wrote:
>> Yes, I have had similar experiences in Linux kernel development for
>> several years.
>> The amount of time to get consensus is one of the reason why I want
>> to move the SQL based row-level security to v8.5 development cycle.
>
> As I stated before, I think doing an SE-Linux version and then adding a
> more generalized solution is doing things in the wrong order because
> the generalized solution is going to have to re-do the SE-Linux stuff.
> As much as I would like to see SE-Linux support in 8.4, I think we need
> general column and row-level permission built with an eye on what
> SE-Linux will need, then add SE-Linux security.

OK, I decided to pay my efforts to implement row-level permission
as soon as possible. Its fundamental idea is same as I posted before.
It enables to assign database ACL per tuples, and enables to filter
violated tuples from the result set of query.

I guess we can see the initial working revision within the next week,
if my design was not wrong.

>> I guess he intend to share the code for row-level security, thus it
>> should be implemented prior to the OS specific feature. But most of
>> SE-PostgreSQL code is separated from core implementation and invoked
>> via security hooks, so it is unsuitable to share code with other
>> facilities.
>
> You are right based on line counts in the patch, but based on actual
> changes to the existing code, SE-Linux changes very much match what
> SQL-level permissions would need.

In my plan, the row-level permission should be mounted on the PGACE
security framework which also mounts SE-PostgreSQL.
In this way, we may be able to sat they share common codes.

> To summarize, 70% of the SE-Linux patch is in stand-alone C files, which
> has little disruption, but 30% are changes to the core backend code,
> which will be disruptive, so we would like to have SQL-level permissions
> that everyone uses to be that disruption, and have SE-Linux attach to
> those capabilities.

It is same as my design.
A new configure option enables to switch the guest of PGACE security framework,
so we will be able to choose one of SE-PostgreSQL, row-level permission and
nothing (default).

[summary of things which I have to do]
(1) To implement row-level permission (*due to the end of Oct*)
(2) To improve SE-PostgreSQL, as I have worked before
(3) To revise the documentatin/specification to wiki articles
for easily publicly accessible.

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

Simon Riggs wrote:
> On Mon, 2008-10-06 at 17:25 +0900, KaiGai Kohei wrote:
>
>> What should I do during the remaining 25 days?
>
> I haven't been following this much, but I note that there is lots of
> confusion over the international standards, guidelines, recommendations,
> specifications etc that we should be following. AFAICS the requirements
> have not been solidified and so there is little scope for examining the
> patch to see if it meets any particular definition of usable.
>
> It would be very useful to write a long Wiki article explaining what
> standards you think the security community want and how those have been
> implemented in your patches. And also ones they don't want and why.
> Maybe you have all that already, so its just a case of exposing it.

I also think what you pointed out is right.

We have the following document, but its description is a bit legacy
as I noted to Peter in the previous message.

http://sepgsql.googlecode.com/files/sepgsql_security_guide.20080214.en.pdf

If they think the wiki article is useful, I can put the revised documentation
and specification as several wiki pages. I'll do it next to the implementation
of row-level permission, because I *have to* submit it due to the deadline.

Here is a request. I hope to collaborate with native English users, because
it is not my native language. :)

Thanks,

> If it is clearly written and easily publicly accessible (no patches
> etc), then we can easily forward these links to people in the right
> communities and they can provide feedback. I will forward to my UK Gov
> contacts if you post a link (and to me, cos I'm not reading these
> threads). Do it soon, please.
>
> Once that's done, it can then be used as an info source for interested
> people once the patch has been accepted, so it will be valuable over
> time.
>
> There's a clear need for Postgres in government and hi-security
> businesses, so we need to get this right. But there's not much point
> doing 65% or 135% of what's needed.
>
> Your efforts and attention are appreciated by all.

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

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. Perhaps I'm
just obtuse (and people should feel free to ignore me, since I'm not
volunteering any code anyway); but this entire discussion seems to me
to lack clear statements of what the goals of the effort are. I know,
"consistent access control"; that still doesn't tell me enough, I
think.

I haven't given it a great deal of thought, but it seems to me that
there are at least a few different goals people have in mind. These
are the ones I've thought of, but I don't pretend this is an
exhaustive list. It certainly isn't based on a serious review of the
literature, which seems to be plentiful:

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, but that there
has been academic work in this area. I think a clear description of
what the costs and benefits of this approach are would go a long way
to helping evaluation. For instance, what sort of side channels does
this expose? Are there database design techniques that help? &c.

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. What is the goal here? Simply
administrator-defined controls on data access inside the database? Is
there a model we're following, or are we making one up? If the
latter, are we sure we're solving all the use cases? What are they?
What are the problems here: for instance, this has exactly the same
sorts of foreign-key issues that swamped the discussion of the
SE-PostgreSQL patches, and I don't see that the new proposal addresses
any of that.

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.

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.

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.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

Hi,

On Sat, Sep 27, 2008 at 12:18:45PM +0900, KaiGai Kohei wrote:
>
> As I repeated several times, SE-PostgreSQL applies the seuciry policy
> of SELinux to achieve consistency in access controls.

I get this. The problem as I see it is that the SELinux security
policy is designed around a very different set of assumptions about
concurrency and consistency than any database system has to provide.
My admittedly hurried glance at some abstracts in the literature
suggests to me that others have looked at the paradoxes that come out
of this kind of security policy consistency when you apply them to
database systems. I think that clearly stating which of the
trade-offs are the ones to be accepted is all that's needed.

> In my vision, Apache assigns its contents handler an individual
> security context based on HTTP authentication, source IP address
> and so on just before web application invoked.
> Because web applications works with individual least privilege set,
> its accesses on filesystem are restricted by the security policy.
> In a similar way, its accesses on databases are also restricted
> via SE-PostgreSQL by same policy, by same privilege set.

I want to focus on this description, because you appear to be limiting
the problem scope tremendously here. We've moved from "general
security policy for database system" to "security policy for database
system as part of a web-application stack". I suggest that the range
of practically available behaviours of the DBMS working as part of a
web-application stack is a subset of the practically available
behaviours of the DBMS overall. This could be the source of some of
the difficulty. For instance, it seems that some scenarios people are
worried about are really the sort of scenario relevant to online users
of Postgres, rather than to people seeing results filtered through a
web application. If we just don't care about the online, interactive
users, then maybe some of those concerns go away. (I'll be honest,
though, that I have a hard time getting excited about a security
system that doesn't really work as advertised outside of a narrow
context.)

All that said, I think there are definite practical uses for the work
you're undertaking, and I want to emphasise that I think the general
goal is probably a good one. I am suggesting that some additional
work clarifying the specific goals of the work is all that's really
needed.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

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>

Andrew Sullivan wrote:
>> In my vision, Apache assigns its contents handler an individual
>> security context based on HTTP authentication, source IP address
>> and so on just before web application invoked.
>> Because web applications works with individual least privilege set,
>> its accesses on filesystem are restricted by the security policy.
>> In a similar way, its accesses on databases are also restricted
>> via SE-PostgreSQL by same policy, by same privilege set.
>
> I want to focus on this description, because you appear to be limiting
> the problem scope tremendously here. We've moved from "general
> security policy for database system" to "security policy for database
> system as part of a web-application stack".

The "general security policy for database system" is an incorrect term.
SELinux does not cover database system only. It covers operating sytem
and application managing objects (like database object, X window, ...).
Thus, it should be talked as "general security policy for operating
system, database system and so on".

A web application stack is one of the most benefitical example.

Please consider what is contained within web-applications.
It accesses objects managed by operating system (like files),
objects managed by database system (like tables) concurrently,
but existing system does not alllow to manage them under a single
unified access control policy.

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

On Fri, Oct 10, 2008 at 01:09:48PM +0900, KaiGai Kohei wrote:

>> 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.

I think I wasn't clear enough. One of the requests we hear all the
time -- indeed, somone just posted an RFQ looking for coders for it --
is a request to prevent users who haven't any permission on a database
to learn anything about it at all. In a shared hosting environment,
for instance, the idea is that two customers can have databases in the
same back end, and not be able to learn anything about one another
_including that they are there_. I am pretty sure I first heard
someone wishing for something like that when was using PostgreSQL
6.something, so it's a long-standing irritant.

Anyway, I'm not trying to suggest, "You should do this." I'm just
trying to point out that what are the obvious areas of access control
from one point of view are not even interesting from another. This is
why I think a fairly complete analysis is needed (and why I think it
hasn't been done yet).

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

On Fri, Oct 10, 2008 at 01:44:49PM +0900, KaiGai Kohei wrote:
> Andrew Sullivan wrote:
>> I want to focus on this description, because you appear to be limiting
>> the problem scope tremendously here. We've moved from "general
>> security policy for database system" to "security policy for database
>> system as part of a web-application stack".
>
> The "general security policy for database system" is an incorrect term.
> SELinux does not cover database system only. It covers operating sytem
> and application managing objects (like database object, X window, ...).
> Thus, it should be talked as "general security policy for operating
> system, database system and so on".

Ok, then let's use the broader case, which is "general security policy
for entire computing system including a RDBM subsystem" (call this
"GSPECS+DB", say). This shows up even more the issue that considering
primarily the application stack does not actually cover all the cases.

I'm not suggesting, even a little bit, that securing an application
stack as you propose is a waste of time. It could be, actually, that
this more modest goal is the more appropriate one, and that
SE-PostgreSQL would be a killer feature in this space (because it
would, if it worked, solve a lot of problems that other systems have,
as you have pointed out). But it is not GSPECS+DB, because of all the
corner case problems whose behaviour still needs working out. Since I
don't have to do any of the work to maintain the system in future in
the face of the proposed new code, I can be indifferent as to whether
the achievement of the goal is worth the cost. But plainly, others
who need to look after the code will want to know what the exact goal
is before committing themselves to future maintenance.

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/

Hi,

It might be relevant for the whole discussion about inclusion of some form of
row level permissions, whatever based on, that there exist heaps of (in my
eyes conflicting) patents about row level permissions for relational
databases. I don't have any real clue about patent issues, but I fear that
makes inclusion into an open source product rather hard...

A list of only some of the patents I know of:

Data security system and method - 5751949 - MCI Corp. - 1998
Rule based database security system and method - 6820082 - Allegis Corporation
- 2004
Row-level security in a relational database management system - 7240046 - IBM
- 2007
Database fine-grained access control - 7281003 - Oracle - 2007

Andres

Andrew Sullivan wrote:
> On Fri, Oct 10, 2008 at 01:44:49PM +0900, KaiGai Kohei wrote:
>> Andrew Sullivan wrote:
>>> I want to focus on this description, because you appear to be limiting
>>> the problem scope tremendously here. We've moved from "general
>>> security policy for database system" to "security policy for database
>>> system as part of a web-application stack".
>> The "general security policy for database system" is an incorrect term.
>> SELinux does not cover database system only. It covers operating sytem
>> and application managing objects (like database object, X window, ...).
>> Thus, it should be talked as "general security policy for operating
>> system, database system and so on".
>
> Ok, then let's use the broader case, which is "general security policy
> for entire computing system including a RDBM subsystem" (call this
> "GSPECS+DB", say). This shows up even more the issue that considering
> primarily the application stack does not actually cover all the cases.
>
> I'm not suggesting, even a little bit, that securing an application
> stack as you propose is a waste of time. It could be, actually, that
> this more modest goal is the more appropriate one, and that
> SE-PostgreSQL would be a killer feature in this space (because it
> would, if it worked, solve a lot of problems that other systems have,
> as you have pointed out). But it is not GSPECS+DB, because of all the
> corner case problems whose behaviour still needs working out.

Indeed, SE-PostgreSQL is an important piece of "GSPECS+DB" but it cannot
catch the ultimate goal by itself only.
Do you know other efforts to apply SELinux security policy for objects
managed in userspace? One prior example is X-window system. Its resources
are managed by X server so in-kernel SELinux cannot trap accesses to the
objects. Some of them (like cut&paste buffer, key input events) can be
shared several processes, so it should be controled by the policy.
We can call it like "GSPECS+X".

As widely known, security is an endless work. The ultimate goal might
not be as near as we can grab, but it does not mean it is not necessary
to fill up pieces to help it.

> But plainly, others who need to look after the code will want to know
> what the exact goal is before committing themselves to future maintenance.

It is same things as I repeated several times.
Its goal is to apply centralized manageable security policy (SELinux) on
database objects, as if SELinux doing on filesystem objects.
This feature can help web-application security, for example.

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

Andres Freund wrote:
> Hi,
>
> It might be relevant for the whole discussion about inclusion of some form of
> row level permissions, whatever based on, that there exist heaps of (in my
> eyes conflicting) patents about row level permissions for relational
> databases. I don't have any real clue about patent issues, but I fear that
> makes inclusion into an open source product rather hard...

I'm not a lawyer, so we cannot decide whether it has patent issue or not
until we get an adjudication in actually. However, I don't think these are
conflicting the existing patent from the viewpoint of engineering.

> Data security system and method - 5751949 - MCI Corp. - 1998
It said the row-level access controls are applied to force users to access
tables via views. It does not conflicts our design.

> Rule based database security system and method - 6820082 - Allegis Corporation - 2004
It said the row-level access controls are applied based on query modifying.
The legacy implementation of SE-PostgreSQL indeed modified WHERE clause of
given queries to apply row-level access controls, but current one does not.

> Row-level security in a relational database management system - 7240046 - IBM - 2007
It said the row-level access controls are applied based on hierarcal relationship
between subject and object, which is well known as Bell-La-PaDula security model.
SE-PostgreSQL does not have any rules by itself, because it depends on an external
security feature (SELinux). Database ACL is not a hierarcal security model obviously.

> Database fine-grained access control - 7281003 - Oracle - 2007
It said the row-level access controls are applied based on query mofifying,
like as the patent 6820082 doing. It does not conflicts to SE-PostgreSQL.

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

KaiGai Kohei wrote:
> OK, I decided to pay my efforts to implement row-level permission
> as soon as possible. Its fundamental idea is same as I posted before.
> It enables to assign database ACL per tuples, and enables to filter
> violated tuples from the result set of query.
>
> I guess we can see the initial working revision within the next week,
> if my design was not wrong.

The following patches are updates of SE-PostgreSQL.
The sixth patch provides row-level database ACL, as I promised before.
Please update the wiki entry to refer the latest patch set.

[1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1120.patch
[2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1120.patch
[3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1120.patch
[4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1120.patch
[5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1120.patch
[6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1120.patch

List of updates:
- The patches are rebased for the HEAD of CVS
- Code cleanups in src/backend/security/sepgsql/proxy.c
- Revising permission checks in FK constraint trigger invocation
- Row-level database ACL feature is added as an alternative option for
row-level access controls.

Some more detailed description will be necessary for the last feature newly added.

------------------------------------------------------------
Row-level database ACL feature
------------------------------------------------------------

* Overview

This feature enables to apply row-level access controls based on database ACL.
It works independently from external security facilities. Any tuples can have
its access control list as table having, and it is checked when the executor
fetches the tuple. The violated tuples are filtered from the result set.

Example:
| tuple_acl | id | name | price |
+-----------------------------------+----+-------+-------+
| {kaigai=rwdx/kaigai,ymj=r/kaigai} | 1 | coke | 120 |
| {kaigai=rwdx/kaigai} | 2 | juice | 150 |
| {kaigai=rwdx/kaigai} | 3 | tea | 103 |
| {kaigai=rwdx/kaigai,ymj=r/kaigai} | 4 | beer | 240 |

In this example, unconditional SELECT returns four tuples for kaigai, but same
query returns two tuples for ymj.

We can activate this feature on the build time with "--enable-row-acl" option
for the configure script. If we omit the option, the built binary works same
as the vanilla PostgreSQL.

Example:
$ ./configure --enable-row-acl --enable-cassert --enable-debug

* Security Design

Its access control policy is based on database ACL which is a sort of
discretional access control (DAC), not a mandatory one. So, it allows resource
owner or privileged users to change its access rights.
As the existing database ACL doing, privileged database roles can also ignore
row-level access controls provided by this feature.

The resource owner of tuple is always same as its relation's owner, because
we have to massive number of pg_depend entries if individual tuple has its
owner.

** The kinds of permissions

This feature enables to assign four kind of permissions to tuples.
These are SELECT, UPDATE, DELETE and REFERENCES. The INSERT permission is
not provided, because an object does not exist when the permission should
be evaluated. All insertion of tuples are controled by database ACL of tables.
It also enables to avoid administrative matter, since table owner is always
same as tuple's one.

** Default ACL

We can setup a default ACL to regular tables. This ACL is assigned to newly
inserted tuples implicitly, if no ACLs are given explicitly.
Enhanced SQL statement can be used to set up default ACL, like:

CREATE TABLE t1 (
a int primary key,
b text
) DEFAULT_ACL = '{kaigai=rwdx/kaigai,=r/kaigai}';

When we insert a tuple into a table without default ACL, the newly inserted
tuple has an empty ACL. This feature handles a tuple with empty ACL as if it
has same ACL of its stored table.
Thus, users can access tuples with empty ACL, because they already have
required privileges for tables.

I think the behavior of empty ACL is an arguable item.
One considerable option is to allow anything for public, to follow the current
bahavior in the vanilla PostgreSQL.

** Special cases

In normal cases, this feature simply filters violated tuples, then it shows
users a result set as if violated tuples are not here.
However, there is an exception in foreign key constraint checks.
When a user tries to delete or update a tuple with primary key which is refered
by invisible foreign key, an error is raised to abort the current query and to
keep referential integrity. It enables users to infer the existance of invisible
fereign keys. It is called as a covert channel in security engeering region.
The row-level access control does not care about the covert channel, so you
should not apply this feature on the region which requires covert channel
elimination.
We recommend not to apply natural keys to avoid actual matter.

* Implementation

This feature is implemented as a guest of PGACE security framework due to
the following two reasons.
The one is we don't have a standard for row-level security to be refered,
so it should be handled as an optional security feature, not a core one.
The other is it provides several useful foundation to implement enhanced
security feature, like security hooks in strategic points, security system
column support and so on. It strongly helps to implement to store row-level
ACL within individual tuples by the minimum impact towards the core PostgreSQL.

** Security system column

We can set up row-level ACL using security system column named as "tuple_acl".
It enables us to confirm what ACL is assigned, as follows:

kaigai=# SELECT tuple_acl, * FROM t1;
tuple_acl | a | b
------------------------------------+---+-----
{kaigai=rwdx/kaigai} | 1 | aaa
{kaigai=rwdx/kaigai,ymj=rd/kaigai} | 2 | bbb
{kaigai=rwdx/kaigai,ymj=r/kaigai} | 3 | ccc
{kaigai=rwdx/kaigai,ymj=rd/kaigai} | 4 | ddd
{kaigai=rwdx/kaigai} | 5 | eee
(5 rows)

The "tuple_acl" is a system column, but writable.
We can modify the "tuple_acl" with UPDATE statement and a function to make ACL
in text representation, as follows:

kaigai=# UPDATE t1 SET tuple_acl = rowacl_revoke(tableoid, tuple_acl,
'kaigai,ymj',
'update,delete');
UPDATE 5
kaigai=# SELECT tuple_acl, * FROM t1 ORDER BY a;
tuple_acl | a | b
---------------------------------+---+-----
{kaigai=rx/kaigai} | 1 | aaa
{kaigai=rx/kaigai,ymj=r/kaigai} | 2 | bbb
{kaigai=rx/kaigai,ymj=r/kaigai} | 3 | ccc
{kaigai=rx/kaigai,ymj=r/kaigai} | 4 | ddd
{kaigai=rx/kaigai} | 5 | eee
(5 rows)

It shows ACL as a test representation, but it does not store the text for
each tuples. It put an additional Oid value on the padding area of
HeapTupleHeader ad "oid" system column doing. It indicates a tuple within
pg_security system catalog, and it holds internal representation.

** Newly added functions

This feature adds three new functions to make ACL in text.
- TEXT rowacl_grant(Oid tableoid, TEXT old_acl,
TEXT user_ids, TEXT permissions)
- TEXT rowacl_revoke(Oid tableoid, TEXT old_acl,
TEXT user_ids, TEXT permissions)
- TEXT rowacl_revoke_cascade(Oid tableoid, TEXT old_acl,
TEXT user_ids, TEXT permissions)

* Backup/Restore

I added "--row-level-acl" option to pg_dump and pg_dumpall.
It enables to dump tables with default ACL and its contents with ACL.

* Example

[kaigai(at)saba ~]$ psql -Ukaigai postgres
psql (8.4devel)
Type "help" for help.

postgres=# CREATE TABLE tbl (
x int primary key,
y text
);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "tbl_pkey" for table "tbl"
CREATE TABLE
postgres=# INSERT INTO tbl VALUES (1,'aaa'),(2,'bbb'),(3,'ccc'),(4,'ddd');
INSERT 0 4
postgres=# GRANT select ON tbl TO ymj;
GRANT
postgres=# UPDATE tbl SET tuple_acl = rowacl_revoke(tableoid, tuple_acl,
'ymj', 'select') WHERE x in (1,4);
UPDATE 2

postgres=# SELECT tuple_acl, * FROM tbl;
tuple_acl | x | y
----------------------+---+-----
| 2 | bbb
| 3 | ccc
{kaigai=rwdx/kaigai} | 1 | aaa
{kaigai=rwdx/kaigai} | 4 | ddd
(4 rows)

postgres=# \q

[kaigai(at)saba ~]$ psql -Uymj postgres
psql (8.4devel)
Type "help" for help.

postgres=> SELECT tuple_acl, * FROM tbl;
tuple_acl | x | y
-----------+---+-----
| 2 | bbb
| 3 | ccc
(2 rows)

postgres=>

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

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> Robert Haas wrote:
>>>> Can you *do* the row-level permission?
>>> I don't think there's any consensus on a design.
>> Yes, unfortunatelly.
>> No one replied to my proposed design:
>> http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2
>
> Yes, we got stuck on the covert channels issue. Frankly I think the use
> of non-natural keys addresses most of the covert channel issues and
> should be recommended for secure setups --- I don't think we are going to
> do any better than that and think we need to move forward on that
> assumption. We can cite
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950, which
> outlines the security risks.

I talked to someone in the Solaris Trusted Extension group last week.
Their stance is basically that they don't worry about covert channels,
because it is too hard or impossible to get right. Their main criterion
about what to hide is what gives existing applications a consistent view
of the world in spite of the presence of additional access controls, for
example to avoid being forced to return errors to applications that
cannot happen in normal circumstances.

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. Perhaps I'm
> just obtuse (and people should feel free to ignore me, since I'm not
> volunteering any code anyway); but this entire discussion seems to me
> to lack clear statements of what the goals of the effort are.

I previously summarized this here:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01067.php

Your list is quite similar, so at least our understandings seem to
converge. :-)

Andrew Sullivan wrote:
> On Fri, Oct 10, 2008 at 01:09:48PM +0900, KaiGai Kohei wrote:
>
> >> 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.
>
> I think I wasn't clear enough. One of the requests we hear all the
> time -- indeed, somone just posted an RFQ looking for coders for it --
> is a request to prevent users who haven't any permission on a database
> to learn anything about it at all. In a shared hosting environment,
> for instance, the idea is that two customers can have databases in the
> same back end, and not be able to learn anything about one another
> _including that they are there_. I am pretty sure I first heard
> someone wishing for something like that when was using PostgreSQL
> 6.something, so it's a long-standing irritant.

I think we could use row-level access control to prevent people from
seeing databases they should not see in pg_database.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> I think we could use row-level access control to prevent people from
> seeing databases they should not see in pg_database.

The row-level database ACL which I submitted yesterdat does not allow
to assign ACLs to tuples within system catalogs (like pg_database),
because it is unclear who should be the owner of tuples.

As I noted at the previous message, it considers the owner of the table
as the owner of the tuples due to several reasons. However, some of system
catalogs have its owner field like "pg_proc.proowner".
This limitation is not a fundamental one, so we can remove it soon.

But, who should be the owner of tuples within system catalogs which have
some kind of "owner" field.

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

KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > I think we could use row-level access control to prevent people from
> > seeing databases they should not see in pg_database.
>
> The row-level database ACL which I submitted yesterdat does not allow
> to assign ACLs to tuples within system catalogs (like pg_database),
> because it is unclear who should be the owner of tuples.
>
> As I noted at the previous message, it considers the owner of the table
> as the owner of the tuples due to several reasons. However, some of system
> catalogs have its owner field like "pg_proc.proowner".
> This limitation is not a fundamental one, so we can remove it soon.
>
> But, who should be the owner of tuples within system catalogs which have
> some kind of "owner" field.

The Postgres super-user should be the owner of all system tables.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> Bruce Momjian wrote:
>>> I think we could use row-level access control to prevent people from
>>> seeing databases they should not see in pg_database.
>> The row-level database ACL which I submitted yesterdat does not allow
>> to assign ACLs to tuples within system catalogs (like pg_database),
>> because it is unclear who should be the owner of tuples.
>>
>> As I noted at the previous message, it considers the owner of the table
>> as the owner of the tuples due to several reasons. However, some of system
>> catalogs have its owner field like "pg_proc.proowner".
>> This limitation is not a fundamental one, so we can remove it soon.
>>
>> But, who should be the owner of tuples within system catalogs which have
>> some kind of "owner" field.
>
> The Postgres super-user should be the owner of all system tables.

OK, I'll update it soon.
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

KaiGai Kohei wrote:
> Bruce Momjian wrote:
>> KaiGai Kohei wrote:
>>> Bruce Momjian wrote:
>>>> I think we could use row-level access control to prevent people from
>>>> seeing databases they should not see in pg_database.
>>> The row-level database ACL which I submitted yesterdat does not allow
>>> to assign ACLs to tuples within system catalogs (like pg_database),
>>> because it is unclear who should be the owner of tuples.
>>>
>>> As I noted at the previous message, it considers the owner of the table
>>> as the owner of the tuples due to several reasons. However, some of
>>> system
>>> catalogs have its owner field like "pg_proc.proowner".
>>> This limitation is not a fundamental one, so we can remove it soon.
>>>
>>> But, who should be the owner of tuples within system catalogs which have
>>> some kind of "owner" field.
>>
>> The Postgres super-user should be the owner of all system tables.
>
> OK, I'll update it soon.

I updates my patches:
[1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1130.patch
[2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1130.patch
[3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1130.patch
[4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1130.patch
[5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1130.patch
[6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1130.patch

List of updates:
- Fixbug: security identifier was not handled correctly on TOAST table
when we repeat to enable/disable the security feature.
- RowACL: remove limitation on system catalogs
- RowACL: the default behavior is changed when we access tuples with no
row-level ACL. The previous version applies ACL inherited from
its table, but the newer one allows anything to public, because
the previous behavior makes problem when you restrict access via
VIEWs.
- RowACL: bugfix when we provide an empty string as a new row-level ACL.

* An example to limit the list of pg_database

[kaigai(at)saba ~]$ psql postgres
psql (8.4devel)
Type "help" for help.

postgres=# CREATE DATABASE test1;
CREATE DATABASE
postgres=# CREATE DATABASE test2;
CREATE DATABASE
postgres=# CREATE DATABASE test3;
CREATE DATABASE
postgres=# UPDATE pg_database SET tuple_acl = '{ymj=r/kaigai}'
WHERE datname like 'test%';
UPDATE 3
postgres=# UPDATE pg_database SET tuple_acl = rowacl_revoke(tableoid, tuple_acl, 'ymj', 'all')
WHERE datname = 'test2';
UPDATE 1
postgres=# \l
List of databases
Name | Owner | Encoding | Collation | Ctype | Access Privileges
-----------+--------+----------+-------------+-------------+-------------------------------
postgres | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 | {=c/kaigai,kaigai=CTc/kaigai}
template1 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 | {=c/kaigai,kaigai=CTc/kaigai}
test1 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
test2 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
test3 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
(6 rows)

postgres=# \q

(*) kaigai (superuser) can see test1, test2 and test3.

[kaigai(at)saba ~]$ psql -Uymj postgres
psql (8.4devel)
Type "help" for help.

postgres=> \l
List of databases
Name | Owner | Encoding | Collation | Ctype | Access Privileges
-----------+--------+----------+-------------+-------------+-------------------------------
postgres | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 | {=c/kaigai,kaigai=CTc/kaigai}
template1 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 | {=c/kaigai,kaigai=CTc/kaigai}
test1 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
test3 | kaigai | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
(5 rows)

(*) ymj (normal user) cannot see test2 because kaigai revoked it.

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

I've updated my patches, these are ready for CommitFest:Nov.

[1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
[2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1155.patch
[3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1155.patch
[4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1155.patch
[5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1155.patch
[6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1155.patch

The comprehensive documentation for SE-PostgreSQL is here:
http://wiki.postgresql.org/wiki/SEPostgreSQL (it is now under reworking.)

List of updates:
- Patches are rebased to the latest CVS HEAD.
- bugfix: TRUNCATE checks assumed SECCLASS_DB_TUPLE object class
- bugfix: sepgsqlCopyFile assumed SECCLASS_FILE object class, but it has to be
adjusted by st_mode.

Request for Comments:
- The 4th patch is actually needed? It can be replaced by wiki page.
- Do you think anything remained towards the final CommitFest?
- Do you have any reviewing comment? Most of patches are unchanged from
the previous vesion. If you can comment anything, I can fix them without
waiting for the final commit fest.

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

On Wed, 2008-10-29 at 17:42 +0900, KaiGai Kohei wrote:

> I've updated my patches, these are ready for CommitFest:Nov.
>
> [1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
> [2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1155.patch
> [3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1155.patch
> [4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1155.patch
> [5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1155.patch
> [6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1155.patch
>
> The comprehensive documentation for SE-PostgreSQL is here:
> http://wiki.postgresql.org/wiki/SEPostgreSQL (it is now under reworking.)
>
> List of updates:
> - Patches are rebased to the latest CVS HEAD.
> - bugfix: TRUNCATE checks assumed SECCLASS_DB_TUPLE object class
> - bugfix: sepgsqlCopyFile assumed SECCLASS_FILE object class, but it has to be
> adjusted by st_mode.
>
> Request for Comments:
> - The 4th patch is actually needed? It can be replaced by wiki page.
> - Do you think anything remained towards the final CommitFest?
> - Do you have any reviewing comment? Most of patches are unchanged from
> the previous vesion. If you can comment anything, I can fix them without
> waiting for the final commit fest.
>

I'm copying some general comments from my contact here, verbatim. Other
comments have been requested and may be forthcoming:

By way of background "Common Criteria" (ISO Standard 15408) are in
effect pre-defined security requirements that have been agreed between
multiple friendly governments so that they can share the results from
independent lab work in each country and avoid the costs and duplication
of effort. The published lab work results in two outputs:
- a "Target of Evaluation" (TOE) i.e. tight definition of the software
version, configuration and environment (hardware, external controls)
which was the subject of the evaluation
- an "Evaluation Report" which, in the "happy case" has assigns an
"Evaluation Assurance Level" (EAL) number to the product (which needless
to say is only valid if the product is used in its TOE

If you're interested in reading more about formal Government security
evaluation schemes, these are some good sites:

General
http://www.commoncriteriaportal.org/

UK
http://www.cesg.gov.uk/

Australia
Defence Signals Directorate www.dsd.gov.au/infosec/

Canada
Communications Security Establishment www.cse.dnd.ca

France
Direction Centrale de la Sécurité des Systèmes d'Information
www.ssi.gouv.fr/en/

Germany
Bundesamt fur Sicherheit in der Informationstechnik www.bsi.bund.de

Japan
Japan Information Technology Security Evaluation and Certification
Scheme (JISEC) www.ipa.go.jp/security/jisec/jisec_e/index.html

USA
National Institute of Standards and Technology www.nist.gov
National Information Assurance Partnership (NIAP)
www.nsa.gov/ia/industry/niap.cfm

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Simon Riggs wrote:
> On Wed, 2008-10-29 at 17:42 +0900, KaiGai Kohei wrote:
>
>> I've updated my patches, these are ready for CommitFest:Nov.
>>
>> [1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1155.patch
>> [2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1155.patch
>> [3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1155.patch
>> [4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1155.patch
>> [5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1155.patch
>> [6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1155.patch
>>
>> The comprehensive documentation for SE-PostgreSQL is here:
>> http://wiki.postgresql.org/wiki/SEPostgreSQL (it is now under reworking.)
>>
>> List of updates:
>> - Patches are rebased to the latest CVS HEAD.
>> - bugfix: TRUNCATE checks assumed SECCLASS_DB_TUPLE object class
>> - bugfix: sepgsqlCopyFile assumed SECCLASS_FILE object class, but it has to be
>> adjusted by st_mode.
>>
>> Request for Comments:
>> - The 4th patch is actually needed? It can be replaced by wiki page.
>> - Do you think anything remained towards the final CommitFest?
>> - Do you have any reviewing comment? Most of patches are unchanged from
>> the previous vesion. If you can comment anything, I can fix them without
>> waiting for the final commit fest.
>>
>
> I'm copying some general comments from my contact here, verbatim. Other
> comments have been requested and may be forthcoming:
>
> By way of background "Common Criteria" (ISO Standard 15408) are in
> effect pre-defined security requirements that have been agreed between
> multiple friendly governments so that they can share the results from
> independent lab work in each country and avoid the costs and duplication
> of effort. The published lab work results in two outputs:
> - a "Target of Evaluation" (TOE) i.e. tight definition of the software
> version, configuration and environment (hardware, external controls)
> which was the subject of the evaluation
> - an "Evaluation Report" which, in the "happy case" has assigns an
> "Evaluation Assurance Level" (EAL) number to the product (which needless
> to say is only valid if the product is used in its TOE
>
> If you're interested in reading more about formal Government security
> evaluation schemes, these are some good sites:

Thanks for your information.
However, I've also followed the Common Criteria for a few years, and
some of facilities came from its requirements. The "security_context"
system column reflects the requirement of labeled import/export, for
example. Don't worry.

Let's move our discussion into its implementation in the upcoming
CommitFest. It's a good time now.

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

I've updated my patches, it contains a few bugfixes.

[1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1168.patch
[2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1168.patch
[3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1168.patch
[4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1168.patch
[5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1168.patch
[6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1168.patch

The comprehensive documentation for SE-PostgreSQL is here:
http://wiki.postgresql.org/wiki/SEPostgreSQL (it is now under reworking.)

List of updates:
- Patches are rebased to the latest CVS HEAD.
- bugfix: permission checks are ignored for per statement trigger functions
- bugfix: per-statement trigger function ignored trusted function configuration
- bugfix: not a proper permission check on lo_export(xxx, '/dev/null')

> Request for Comments:
> - The 4th patch is actually needed? It can be replaced by wiki page.
> - Do you think anything remained towards the final CommitFest?
> - Do you have any reviewing comment? Most of patches are unchanged from
> the previous vesion. If you can comment anything, I can fix them without
> waiting for the final commit fest.

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

KaiGai Kohei wrote:
> I've updated my patches, it contains a few bugfixes.
>
> [1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1168.patch
> [2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1168.patch
> [3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1168.patch
> [4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1168.patch
> [5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1168.patch
> [6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1168.patch
>
> The comprehensive documentation for SE-PostgreSQL is here:
> http://wiki.postgresql.org/wiki/SEPostgreSQL (it is now under reworking.)
>
> List of updates:
> - Patches are rebased to the latest CVS HEAD.
> - bugfix: permission checks are ignored for per statement trigger functions
> - bugfix: per-statement trigger function ignored trusted function configuration
> - bugfix: not a proper permission check on lo_export(xxx, '/dev/null')
>
> > Request for Comments:
> > - The 4th patch is actually needed? It can be replaced by wiki page.
> > - Do you think anything remained towards the final CommitFest?
> > - Do you have any reviewing comment? Most of patches are unchanged from
> > the previous vesion. If you can comment anything, I can fix them without
> > waiting for the final commit fest.

I just looked over the patch. This new version with row-level SQL
security has certainly reduced the SE-Linux-specific part, which is
good.

It was interesting how you implemented SQL-level column-level
permissions:

CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32) SECURITY_CONTEXT = 'system_u:object_r:sepgsql_secret_table_t'
);

I am unclear how that will behave with the column-level permissions
patch someone is working on. I am wondering if your approach is clearer
than the other patch because it gives a consistent right policy for rows
and columns.

I was wondering why you mention the NSA (U.S. National Security Agency)
in the patch?

+# NSA SELinux support

The size of the patch is still larger but I don't see any way to reduce it:

1275 sepostgresql-docs-8.4devel-3-r1168.patch
625 sepostgresql-pg_dump-8.4devel-3-r1168.patch
829 sepostgresql-policy-8.4devel-3-r1168.patch
1736 sepostgresql-row_acl-8.4devel-3-r1168.patch
10847 sepostgresql-sepgsql-8.4devel-3-r1168.patch
1567 sepostgresql-tests-8.4devel-3-r1168.patch
16879 total

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> I've updated my patches, it contains a few bugfixes.

> I was wondering why you mention the NSA (U.S. National Security Agency)
> in the patch?

NSA is who create SELinux originally IIRC.

Joshua D. Drake

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> I've updated my patches, it contains a few bugfixes.
>>
>> [1/6] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1168.patch
>> [2/6] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1168.patch
>> [3/6] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1168.patch
>> [4/6] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1168.patch
>> [5/6] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1168.patch
>> [6/6] http://sepgsql.googlecode.com/files/sepostgresql-row_acl-8.4devel-3-r1168.patch
>>
>> The comprehensive documentation for SE-PostgreSQL is here:
>> http://wiki.postgresql.org/wiki/SEPostgreSQL (it is now under reworking.)
>>
>> List of updates:
>> - Patches are rebased to the latest CVS HEAD.
>> - bugfix: permission checks are ignored for per statement trigger functions
>> - bugfix: per-statement trigger function ignored trusted function configuration
>> - bugfix: not a proper permission check on lo_export(xxx, '/dev/null')
>>
>>> Request for Comments:
>>> - The 4th patch is actually needed? It can be replaced by wiki page.
>>> - Do you think anything remained towards the final CommitFest?
>>> - Do you have any reviewing comment? Most of patches are unchanged from
>>> the previous vesion. If you can comment anything, I can fix them without
>>> waiting for the final commit fest.
>
> I just looked over the patch. This new version with row-level SQL
> security has certainly reduced the SE-Linux-specific part, which is
> good.
>
> It was interesting how you implemented SQL-level column-level
> permissions:
>
> CREATE TABLE customer (
> cid integer primary key,
> cname varchar(32),
> credit varchar(32) SECURITY_CONTEXT = 'system_u:object_r:sepgsql_secret_table_t'
> );
>
> I am unclear how that will behave with the column-level permissions
> patch someone is working on. I am wondering if your approach is clearer
> than the other patch because it gives a consistent right policy for rows
> and columns.

The column-level permissions in SE-PostgreSQL works independently and
orthogonally from the upcoming column-level permissions by Stephen Frost.
When the SE-PostgreSQL is enabled, both of facilities have to allow the
client to access required columns.

In the above case, the "credit" column has "sepgsql_secret_table_t" type,
but rest of columns inherits the type of "customer" table which allows
non-administrative users to access in the default security policy.
If the given query contains the "credit" column, SE-PostgreSQL checks
privileges of client to access columns labeled as "sepgsql_secret_table_t",
then it raises an error to abort the current transaction if the security
policy does not allow it.

There is a possibility that column-level ACLs are set via newer GRANT/REVOKE
statement. In this case, the core PostgreSQL checks them, and raises an error
if violated.

> I was wondering why you mention the NSA (U.S. National Security Agency)
> in the patch?
>
> +# NSA SELinux support

The original author of SELinux is NSA.
There is no more meanings than a caption of the option.
I'll fix it, if necessary.

> The size of the patch is still larger but I don't see any way to reduce it:
>
> 1275 sepostgresql-docs-8.4devel-3-r1168.patch
> 625 sepostgresql-pg_dump-8.4devel-3-r1168.patch
> 829 sepostgresql-policy-8.4devel-3-r1168.patch
> 1736 sepostgresql-row_acl-8.4devel-3-r1168.patch
> 10847 sepostgresql-sepgsql-8.4devel-3-r1168.patch
> 1567 sepostgresql-tests-8.4devel-3-r1168.patch
> 16879 total

I thought the "sepostgresql-docs" can be replaced by the pointing to the wiki
page, how do you think the idea?

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

KaiGai Kohei wrote:
> > I just looked over the patch. This new version with row-level SQL
> > security has certainly reduced the SE-Linux-specific part, which is
> > good.
> >
> > It was interesting how you implemented SQL-level column-level
> > permissions:
> >
> > CREATE TABLE customer (
> > cid integer primary key,
> > cname varchar(32),
> > credit varchar(32) SECURITY_CONTEXT = 'system_u:object_r:sepgsql_secret_table_t'
> > );
> >
> > I am unclear how that will behave with the column-level permissions
> > patch someone is working on. I am wondering if your approach is clearer
> > than the other patch because it gives a consistent right policy for rows
> > and columns.
>
> The column-level permissions in SE-PostgreSQL works independently and
> orthogonally from the upcoming column-level permissions by Stephen Frost.
> When the SE-PostgreSQL is enabled, both of facilities have to allow the
> client to access required columns.
>
> In the above case, the "credit" column has "sepgsql_secret_table_t" type,
> but rest of columns inherits the type of "customer" table which allows
> non-administrative users to access in the default security policy.
> If the given query contains the "credit" column, SE-PostgreSQL checks
> privileges of client to access columns labeled as "sepgsql_secret_table_t",
> then it raises an error to abort the current transaction if the security
> policy does not allow it.
>
> There is a possibility that column-level ACLs are set via newer GRANT/REVOKE
> statement. In this case, the core PostgreSQL checks them, and raises an error
> if violated.

OK. I am wondering if we _want_ two ways to set column permisions,
especially since I think there will be only one way to set row-level
permissions.

> > I was wondering why you mention the NSA (U.S. National Security Agency)
> > in the patch?
> >
> > +# NSA SELinux support
>
> The original author of SELinux is NSA.
> There is no more meanings than a caption of the option.
> I'll fix it, if necessary.

Yes, please remove; the "NSA" suggests to me that this is an NSA-only
feature, which it is not; it was just originally designed for them.

> > The size of the patch is still larger but I don't see any way to reduce it:
> >
> > 1275 sepostgresql-docs-8.4devel-3-r1168.patch
> > 625 sepostgresql-pg_dump-8.4devel-3-r1168.patch
> > 829 sepostgresql-policy-8.4devel-3-r1168.patch
> > 1736 sepostgresql-row_acl-8.4devel-3-r1168.patch
> > 10847 sepostgresql-sepgsql-8.4devel-3-r1168.patch
> > 1567 sepostgresql-tests-8.4devel-3-r1168.patch
> > 16879 total
>
> I thought the "sepostgresql-docs" can be replaced by the pointing to the wiki
> page, how do you think the idea?

No, I docs for using the tarball should be in the main documentation,
even if they are not compile-enabled by default. The new patch affects
the main Postgres backend code much less, which is a great improvement.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>>> I just looked over the patch. This new version with row-level SQL
>>> security has certainly reduced the SE-Linux-specific part, which is
>>> good.
>>>
>>> It was interesting how you implemented SQL-level column-level
>>> permissions:
>>>
>>> CREATE TABLE customer (
>>> cid integer primary key,
>>> cname varchar(32),
>>> credit varchar(32) SECURITY_CONTEXT = 'system_u:object_r:sepgsql_secret_table_t'
>>> );
>>>
>>> I am unclear how that will behave with the column-level permissions
>>> patch someone is working on. I am wondering if your approach is clearer
>>> than the other patch because it gives a consistent right policy for rows
>>> and columns.
>> The column-level permissions in SE-PostgreSQL works independently and
>> orthogonally from the upcoming column-level permissions by Stephen Frost.
>> When the SE-PostgreSQL is enabled, both of facilities have to allow the
>> client to access required columns.
>>
>> In the above case, the "credit" column has "sepgsql_secret_table_t" type,
>> but rest of columns inherits the type of "customer" table which allows
>> non-administrative users to access in the default security policy.
>> If the given query contains the "credit" column, SE-PostgreSQL checks
>> privileges of client to access columns labeled as "sepgsql_secret_table_t",
>> then it raises an error to abort the current transaction if the security
>> policy does not allow it.
>>
>> There is a possibility that column-level ACLs are set via newer GRANT/REVOKE
>> statement. In this case, the core PostgreSQL checks them, and raises an error
>> if violated.
>
> OK. I am wondering if we _want_ two ways to set column permisions,
> especially since I think there will be only one way to set row-level
> permissions.

I think we should not see the feature from only the viewpoint of granularity
in access controls. The both of new security features (sepgsql and rowacl)
are enhanced security features, but the Stephen's efforts is one of the core
features based on SQL-standard and enabled in the default.
Please pay mention that any given queries have to be checked by the core
facility, and can be checked by the enhanced one if enabled.

The PGACE security framework enables us to implement various kind of enhanced
security features, and has two guest facilities now. They can have its own
security model and granularities as a part of its design.
The one has its granularities with some of overlaps on tables/columns/functions,
and the other also has its granularity without overlaps because its purpose is
supplement of the core security facilities.

So, it is not a strange design there is only one way to set row-level permissions,
because the current SQL-standard does not have its specifications and no core
facilities are here.
If the future version of PostgreSQL got a newer row-level permissions defined
within SQL-standard, I think there should be two ways to set row-level ones
for both of the core and enhanced.

>>> I was wondering why you mention the NSA (U.S. National Security Agency)
>>> in the patch?
>>>
>>> +# NSA SELinux support
>> The original author of SELinux is NSA.
>> There is no more meanings than a caption of the option.
>> I'll fix it, if necessary.
>
> Yes, please remove; the "NSA" suggests to me that this is an NSA-only
> feature, which it is not; it was just originally designed for them.

OK, I modified the caption from "NSA SELinux" to "SELinux".

http://code.google.com/p/sepgsql/source/detail?r=1170

>>> The size of the patch is still larger but I don't see any way to reduce it:
>>>
>>> 1275 sepostgresql-docs-8.4devel-3-r1168.patch
>>> 625 sepostgresql-pg_dump-8.4devel-3-r1168.patch
>>> 829 sepostgresql-policy-8.4devel-3-r1168.patch
>>> 1736 sepostgresql-row_acl-8.4devel-3-r1168.patch
>>> 10847 sepostgresql-sepgsql-8.4devel-3-r1168.patch
>>> 1567 sepostgresql-tests-8.4devel-3-r1168.patch
>>> 16879 total
>> I thought the "sepostgresql-docs" can be replaced by the pointing to the wiki
>> page, how do you think the idea?
>
> No, I docs for using the tarball should be in the main documentation,
> even if they are not compile-enabled by default. The new patch affects
> the main Postgres backend code much less, which is a great improvement.

OK, I could understand it.

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

KaiGai Kohei wrote:
> > OK. I am wondering if we _want_ two ways to set column permisions,
> > especially since I think there will be only one way to set row-level
> > permissions.
>
> I think we should not see the feature from only the viewpoint
> of granularity in access controls. The both of new security
> features (sepgsql and rowacl) are enhanced security features,
> but the Stephen's efforts is one of the core features based on
> SQL-standard and enabled in the default. Please pay mention
> that any given queries have to be checked by the core facility,
> and can be checked by the enhanced one if enabled.
>
> The PGACE security framework enables us to implement various
> kind of enhanced security features, and has two guest facilities
> now. They can have its own security model and granularities as
> a part of its design. The one has its granularities with some
> of overlaps on tables/columns/functions, and the other also has
> its granularity without overlaps because its purpose is supplement
> of the core security facilities.
>
> So, it is not a strange design there is only one way to set
> row-level permissions, because the current SQL-standard does
> not have its specifications and no core facilities are here.
> If the future version of PostgreSQL got a newer row-level
> permissions defined within SQL-standard, I think there should
> be two ways to set row-level ones for both of the core and
> enhanced.

OK, I understand. Thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +