Thread: 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@ak.jp.nec.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@ak.jp.nec.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@kaigai.gr.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@momjian.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@ak.jp.nec.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@momjian.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@ak.jp.nec.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@momjian.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@ak.jp.nec.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.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@momjian.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/WhatIsPGACEDatum pgacePreparePlanCheck(Relation rel)It is invoked just before callinga function which implements fereignkey constraint.The major purpose of this hook is to keep consistency in the lowestlevel.It enables to notify the guest the beginning of checks in foreignkey constraint. The guest can change the behaviorof tuple level accesscontrol between pgacePreparePlanCheck() and pgaceRestorePlanCheck(). --> In SE-PostgreSQL case, access controls in tuple level are normally donewith filtering any violated tuple. However,it can prevent to checkforeign key constraint, because caller cannot recognize whether no tuplerefers the primaryrelation, or any tuple refering are filtered.Therefore, SE-PostgreSQL aborts the current transaction if any violatedtuplerefering the primary relation. -- Bruce Momjian <bruce@momjian.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@ak.jp.nec.com>
Tom Lane wrote: > Bruce Momjian <bruce@momjian.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@ak.jp.nec.com>
"Robert Haas" <robertmhaas@gmail.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@momjian.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@ak.jp.nec.com>
"Robert Haas" <robertmhaas@gmail.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@momjian.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@gmail.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@ak.jp.nec.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@momjian.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@momjian.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Robert Haas" <robertmhaas@gmail.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@momjian.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@ak.jp.nec.com>
Bruce Momjian <bruce@momjian.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 implementationbefore. 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@ak.jp.nec.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@momjian.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@ak.jp.nec.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 notnecessarily 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 numbermeans 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@ak.jp.nec.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@ak.jp.nec.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) thisis 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@commandprompt.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@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
Andrew Sullivan <ajs@commandprompt.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@kaigai.gr.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@commandprompt.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@momjian.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@gmail.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.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@commandprompt.com +1 503 667 4564 x104 http://www.commandprompt.com/
Tom Lane wrote: > Bruce Momjian <bruce@momjian.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 ofpolyinstantiation [Denning 87]. Polyinstantiation forces a relationtocontain multiple tuples with the same primary key but distinguishable bytheir classification levels or by the non-primarykey attributes of therelation [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@momjian.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@commandprompt.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 ofpeer 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@kaigai.gr.jp>
Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian <bruce@momjian.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@kaigai.gr.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 happenand to what extent, and does that justify the significantinvestment 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@momjian.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@momjian.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@ak.jp.nec.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@ak.jp.nec.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@ak.jp.nec.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@ak.jp.nec.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-PostgreSQLnow got merged into the upstream selinux-policy package. - Add a "Limitation" section to describe aboutcovert channel and reference integrity. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.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@ak.jp.nec.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@ak.jp.nec.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@kaigai.gr.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@kaigai.gr.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@ak.jp.nec.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@momjian.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@momjian.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.comPostgreSQL 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@ak.jp.nec.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@ak.jp.nec.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@commandprompt.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@commandprompt.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@ak.jp.nec.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@ak.jp.nec.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@commandprompt.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@commandprompt.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 themselvesto 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@ak.jp.nec.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@ak.jp.nec.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@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@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@ak.jp.nec.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@momjian.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@ak.jp.nec.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@momjian.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@ak.jp.nec.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 securityfeature. - RowACL: remove limitation on system catalogs - RowACL: the default behavior is changed when we access tuples with no row-level ACL. The previous version appliesACL inherited from its table, but the newer one allows anything to public, because the previousbehavior 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@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@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@ak.jp.nec.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 underreworking.) 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@ak.jp.nec.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.comPostgreSQL 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@ak.jp.nec.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 underreworking.) 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@ak.jp.nec.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@momjian.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@kaigai.gr.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@momjian.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@ak.jp.nec.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +