Re: SE-PgSQL patch review

I'm reviewing SE-PgSQL patch and have some comments.
https://commitfest.postgresql.org/action/patch_view?id=212

Forgive me, but I'm a novice of SELinux. Some of the comments
and question might be nonsense.

==== Patch overview ====
The patch itself is large (>13K), but more than half of it are
well-written regression test, comments and README.

It adds object-level and column-level security checks after normal
permission checks. Row-level checks are not included in the patch.

==== Syntax and identifier names ====
* Can we use "security context" only for securty checking but also
for general "context" handling? If so, we can call it just "context".
It might be useful if the context is designed for more general purpose.
For example, we could develop context-based logging or contex-aware
setting parameters. I think "Application Name" patch is one of the
implementations of context-based logging.
https://commitfest.postgresql.org/action/patch_view?id=195

* CREATE TABLE tbl (...) SECURITY_CONTEXT = '...'
IMHO, '_' and '=' don't suit for SQL.
If there are no conflicts in gram.y, how about removing them?
CREATE TABLE tbl (...) SECURITY CONTEXT '...'

* CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
Is the syntax "<AS> SECURITY_CONTEXT" natural in English?

* Since SE-PgSQL will be integrated into the core, we can use pg_*
names for the feature. For example, we can rename sepgsql_getcon() to
pg_get_security_context(). Also, we should not use 'con' as an
abbreviated form of 'context' because we often use it for 'connection'.
The same can be said for GUC parameter names.
(ex: "sepostgresql" to be "security_policy")

==== Error messages and error codes ====
* It uses dedicated 'SExxx' error codes, but I think they should belong to
the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501).
/* Class SE - SE-PostgreSQL Error (SE-PgSQL-specific error class) */
#define ERRCODE_SELINUX_INTERNAL_ERROR MAKE_SQLSTATE('S','E', '0','0','1')
#define ERRCODE_INVALID_SECURITY_CONTEXT MAKE_SQLSTATE('S','E', '0','0','2')
#define ERRCODE_SELINUX_AUDIT_LOG MAKE_SQLSTATE('S','E', '0','0','3')

* Can we use error messages that looks like existing privilege errors?
ERRCODE_INSUFFICIENT_PRIVILEGE:
=> permission denied to rename database
Error messages from SE-PgSQL
=> SE-PgSQL prevents to modify "pg_class" by hand
looks very different. I'd suggest something like
=> security context denied to rename database

I'll suggest we avoid using the term "SE-PgSQL" in the user visible
message and documentation because because the feature will be integrated
into the core deeply. Of course, we can use "SE-PgSQL" in *promotion*.

==== Internal structures ====
* Are the security labels enough stable?
What will we need when SELinux configuration is modified?
We store security labels as text for each object and column.

* Each security checks are called after pg_*_aclcheck(). Is it possible to
merge SE-PgSQL checks into ACL functions in aclchk.c ?

* What is difference between sepgsql_database_getcon(oid) and
pg_database.datsecon? Why do we need those getcon functions?

That's all comments for now. I'll test the patch in actual machines next.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

Itagaki Takahiro wrote:
> I'm reviewing SE-PgSQL patch and have some comments.
> https://commitfest.postgresql.org/action/patch_view?id=212
>
> Forgive me, but I'm a novice of SELinux. Some of the comments
> and question might be nonsense.

Itagaki-san, thanks for your volunteering so much!

> ==== Patch overview ====
> The patch itself is large (>13K), but more than half of it are
> well-written regression test, comments and README.
>
> It adds object-level and column-level security checks after normal
> permission checks. Row-level checks are not included in the patch.

Yes, I separated most of features to reduce code size.
The developer documentation and source code comments were added instead.

> ==== Syntax and identifier names ====
> * Can we use "security context" only for securty checking but also
> for general "context" handling? If so, we can call it just "context".
> It might be useful if the context is designed for more general purpose.
> For example, we could develop context-based logging or contex-aware
> setting parameters. I think "Application Name" patch is one of the
> implementations of context-based logging.
> https://commitfest.postgresql.org/action/patch_view?id=195

The "security context" is a proper-noun in SELinux.
I don't think it is a good idea to call it just a "context".

If we have a set of properties of the client called as a context,
security context is one of the property in a context, such as user
identifier, application name and so on.

If Log_line_prefix supports the security context of the client,
it seems me a good idea. (However, we can implement it in the future.)

BTW, SELinux also provides indications about what should be logged
on access violation events. It is also an duty of userspace object
manager. See the sepgsql_audit_log() in selinux.c.

> * CREATE TABLE tbl (...) SECURITY_CONTEXT = '...'
> IMHO, '_' and '=' don't suit for SQL.
> If there are no conflicts in gram.y, how about removing them?
> CREATE TABLE tbl (...) SECURITY CONTEXT '...'

I tried it, and it seems to me fine.

> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
> Is the syntax "<AS> SECURITY_CONTEXT" natural in English?

We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
to avoid syntax conflicts to "DEFAULT b_expr" option.

> * Since SE-PgSQL will be integrated into the core, we can use pg_*
> names for the feature. For example, we can rename sepgsql_getcon() to
> pg_get_security_context(). Also, we should not use 'con' as an
> abbreviated form of 'context' because we often use it for 'connection'.
> The same can be said for GUC parameter names.

What is your opinion for '*_secon()', instead of '*_security_context'?
If OK, these functions will be renamed as follows:

- sepgsql_template1_getcon -> pg_get_template1_secon
- sepgsql_default_getcon -> pg_get_default_secon
- sepgsql_getcon -> pg_get_client_secon
- sepgsql_database_getcon -> pg_get_database_secon
- sepgsql_schema_getcon -> pg_get_schema_secon
- sepgsql_relation_getcon -> pg_get_relation_secon
- sepgsql_attribute_getcon -> pg_get_attribute_secon

> (ex: "sepostgresql" to be "security_policy")

I prefer "selinux_support" more than "security_policy", because
it is a noun to mean a set of access control rules in the kernel.

> ==== Error messages and error codes ====
> * It uses dedicated 'SExxx' error codes, but I think they should belong to
> the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501).
> /* Class SE - SE-PostgreSQL Error (SE-PgSQL-specific error class) */
> #define ERRCODE_SELINUX_INTERNAL_ERROR MAKE_SQLSTATE('S','E', '0','0','1')
> #define ERRCODE_INVALID_SECURITY_CONTEXT MAKE_SQLSTATE('S','E', '0','0','2')
> #define ERRCODE_SELINUX_AUDIT_LOG MAKE_SQLSTATE('S','E', '0','0','3')

I already uses predefined error code, if exist.
For example, sepgsql_compute_perms() is the routine to make access control
decision in SELinux. It uses ERRCODE_INSUFFICIENT_PRIVILEGE, when it needs
to raise an error.

extern bool
sepgsql_compute_perms(char *scontext, char *tcontext,
uint16 tclass, uint32 required,
const char *audit_name, bool abort)
{
:
/*
* It asks SELinux whether the given access should be allowed,
* or not. It set the given avd structure correctly, then returns.
*/
compute_perms_internal(scontext, tcontext, tclass, &avd);
:
/*
* If here is no policy violations, or SE-PgSQL performs in permissive
* mode, or the client process peforms in permissive domain, it returns
* normally with 'true'.
*/
if (!denied ||
!sepgsql_get_enforce() ||
(avd.flags & SELINUX_AVD_FLAGS_PERMISSIVE) != 0)
return true;
:
/*
* Otherwise, it raises an error or returns 'false', depending on the
* caller's indication by 'abort'.
*/
if (abort)
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("SELinux: security policy violation")));

return false;
}

These error codes has its own meanings.
* ERRCODE_SELINUX_INTERNAL_ERROR
It is an error due to the communication between PostgreSQL and SELinux.
It seems similar to ERRCODE_INTERNAL_ERROR, but it is not "can't-happen"
conditions, so I defined it individually.

* ERRCODE_INVALID_SECURITY_CONTEXT
It is used when client gives an invalid security context on CREATE or
ALTER statement. I could not find any similar predefined error code.

* ERRCODE_SELINUX_AUDIT_LOG
It is used when SE-PgSQL generates access violation logs, not an error.
I also could not find any similar predefined error code.

> * Can we use error messages that looks like existing privilege errors?
> ERRCODE_INSUFFICIENT_PRIVILEGE:
> => permission denied to rename database

Here is a point that we should provide users a hint which enables
to make clear the reason of access violations. So, I think we should
contains a mark to show it come from SE-PgSQL.

Currently, it raises an error on access violation in sepgsql_compute_perms().
It always prints out "SELinux: security policy violation".

> Error messages from SE-PgSQL
> => SE-PgSQL prevents to modify "pg_class" by hand
> looks very different. I'd suggest something like
> => security context denied to rename database

If we follow the existing manner, it may be:
"SELinux: permission denied: \"%s\" is a system catalog"

> I'll suggest we avoid using the term "SE-PgSQL" in the user visible
> message and documentation because because the feature will be integrated
> into the core deeply. Of course, we can use "SE-PgSQL" in *promotion*.

If we use another name for the feature, "SELinux support" may be preferable?

> ==== Internal structures ====
> * Are the security labels enough stable?
> What will we need when SELinux configuration is modified?
> We store security labels as text for each object and column.

If the security labels get invalid due to the modification of SELinux
configuration or other reasons, it considers the database objects are
unlabeled.

Whenever we fetch a text representation of security label from system
catalog, it invokes security_check_context_raw() to check whether the
security label is valid on the current configuration, or not.

If invalid, it obtains an "unlabeled" security context from the system.

For example,

bool
sepgsql_database_common(Oid datOid, uint32 required, bool abort)
{
:
/*
* (1) It fetches a security context from pg_database.datsecon
* as a text data.
*/
tuple = SearchSysCache(DATABASEOID,
ObjectIdGetDatum(datOid),
0, 0, 0);
if (!HeapTupleIsValid(tuple))
elog(ERROR, "cache lookup failed for database %u", datOid);

datsecon = SysCacheGetAttr(DATABASEOID, tuple,
Anum_pg_database_datsecon, &isnull);
if (!isnull)
context = TextDatumGetCString(datsecon);
/*
* (2) If the fetched security context is not a valid one,
* we obtain system's "unlabeled" security context as a fallback.
* - security_check_context_raw() applies validation checks
* - sepgsql_get_unlabeled_context() returns "unlabeled" context.
* Typically, it is "system_u:object_r:unlabeled_t:s0"
*/
if (!context || security_check_context_raw(context) < 0)
context = sepgsql_get_unlabeled_context();
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/*
* (3) We call permission check routine on a couple of security
* contexts (client and the target database).
* It may be a valid security context, or "unlabeld" security
* context. In either case, we can provide a valid security context.
*/
audit_name = NameStr(((Form_pg_database) GETSTRUCT(tuple))->datname);
rc = sepgsql_compute_perms(sepgsql_get_client_context(),
context,
SEPG_CLASS_DB_DATABASE,
required,
audit_name, abort);
ReleaseSysCache(tuple);

return rc;
}

> * Each security checks are called after pg_*_aclcheck(). Is it possible to
> merge SE-PgSQL checks into ACL functions in aclchk.c ?

It is impossible due to some reasons.

For example, some of entrypoints are enclosed by "if (superuser())".
It implicitly allows any clients with superuser attribute to bypass MAC
checks, but it is quite violates SE-PgSQL's design, if we put the hooks
in the PG default model routines.

For example, SE-PgSQL model distinguish "setattr" permission from "drop".
But pg_class_ownercheck() is used for both ALTER and DROP statement.
So, we cannot know which permission should be applied inside from the
pg_class_ownercheck().

For example, ...

We already tried to provide a common set of entrypoints for both of DAC
and MAC at the last commit fest ("Reworks for Access Controls" patch).
This abstraction layer had to provide enough information to make access
control decisions for both of models, and be deployed on the strategic
points for both models. But it needed massive amount of reworks in the
core routines, so we decided this approach is not a right direction.

> * What is difference between sepgsql_database_getcon(oid) and
> pg_database.datsecon? Why do we need those getcon functions?

SELinux allows to translate the last field of security context between
a human readable form and a raw form.

For example, if a table is labeled as follows:
system_u:object_r:sepgsql_table_t:s0:c1
^^^^^
We call this field as "range" or "mcs label". In the raw-format, it is
a complex of symbols, but we can assign human meaningfull alias on them.
If "s0:c1" has its alias ("1st_sales_division"), above security context
shall be printed as:
system_u:object_r:sepgsql_table_t:1st_sales_division
^^^^^^^^^^^^^^^^^^
This feature is called "mcstrans".
It is necessary to port a definition of security context to other hosts
which may not have same mapping between a human-readable and raw format.

Thus, I used sepgsql_xxxx_getcon() function in the pg_dump to follows
the manner in SELinux when we export/import security context of objects
from/to the object manager (PostgreSQL).

I'll revise the following things at first:
- Replace SE-PgSQL from user visible error messages and documentations.
- SECURITY_CONTEXT [=] '<label>' to be SECURITY CONTEXT '<label>'

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

>> * Can we use error messages that looks like existing privilege errors?
>> ERRCODE_INSUFFICIENT_PRIVILEGE:
>> => permission denied to rename database
>
> Here is a point that we should provide users a hint which enables
> to make clear the reason of access violations. So, I think we should
> contains a mark to show it come from SE-PgSQL.
>
> Currently, it raises an error on access violation in sepgsql_compute_perms().
> It always prints out "SELinux: security policy violation".

It is just for your information.

SELinux allows end-users to confirm what accesses are violated using audit logs.
In operating system, it is written on the /var/log/audit/audit.log.

See the result of:
% grep ^type=AVC /var/log/audit/audit.log
:
type=AVC msg=audit(1258412043.107:81): avc: denied { search } for pid=1750 comm="httpd" name="root" dev=sda5 ino=1062881 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
:

In SE-PgSQL, it writes out detailed information about access violations
on log files. Then, it can be used to revise security policy.

For example:
postgres=# UPDATE t1 SET a = 1;
ERROR: SELinux: security policy violation

It shall be logged as follows:
LOG: SELinux: denied { update } scontext=unconfined_u:unconfined_r:sepgsql_test_t:Unclassified tcontext=system_u:object_r:sepgsql_ro_table_t:Classified tclass=db_table name=t1
STATEMENT: UPDATE t1 SET a = 1;
ERROR: SELinux: security policy violation
STATEMENT: UPDATE t1 SET a = 1;

We can also provide these logs to analyzer programs to pop-up a hint for
trouble-shooting (setroubleshoot), to generate policy module automatically
from access violation logs (audit2allow), and so on.

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

On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
> Itagaki Takahiro wrote:
> > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
> > Is the syntax "<AS> SECURITY_CONTEXT" natural in English?
>
> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
> to avoid syntax conflicts to "DEFAULT b_expr" option.

Does "WITH" work? Seems to read better to me:

CREATE TABLE tbl (col integer WITH SECURITY CONTEXT [...])

--
Ross Reedstrom, Ph.D. reedstrm(at)rice(dot)edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
The Connexions Project http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE

Ross J. Reedstrom wrote:
> On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
>> Itagaki Takahiro wrote:
>>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>>> Is the syntax "<AS> SECURITY_CONTEXT" natural in English?
>> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
>> to avoid syntax conflicts to "DEFAULT b_expr" option.
>
> Does "WITH" work? Seems to read better to me:
>
> CREATE TABLE tbl (col integer WITH SECURITY CONTEXT [...])
>
It was conflicted. :(

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

KaiGai Kohei wrote:
> Ross J. Reedstrom wrote:
>> On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
>>> Itagaki Takahiro wrote:
>>>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>>>> Is the syntax "<AS> SECURITY_CONTEXT" natural in English?
>>> We need to put a reserved token, such as "AS", prior to the
>>> SECURITY_CONTEXT
>>> to avoid syntax conflicts to "DEFAULT b_expr" option.
>>
>> Does "WITH" work? Seems to read better to me:
>>
>> CREATE TABLE tbl (col integer WITH SECURITY CONTEXT [...])
>>
> It was conflicted. :(

BTW, we have two options, if we don't use AS token here.

1. It moves "SECURITY" to reserved keyword.
We can represent SECURITY CONTEXT option for each columns quite
natural, but it also has a pain. It disallow to use "security"
as a column name.

2. Another syntax to support SECURITY CONTEXT
For example:
CREATE TABLE tbl_name (
col_X_name int primary key,
col_Y_name text default 'aaa'
) SECURITY CONTEXT ( 'label of the table',
col_Y_name IS 'label of the column Y', ... );

I don't have any preference between the current syntax and the new one.

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

KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:

> > CREATE TABLE tbl (...) SECURITY CONTEXT '...'
> > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>
> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
> to avoid syntax conflicts to "DEFAULT b_expr" option.

There might be another idea to put security context in WITH options:
1. CREATE TABLE tbl (...) WITH (security_context = '...')
2. CREATE TABLE tbl (col integer WITH (security_context = '...') PRIMARY KEY)
If we use the syntax, '_' and '=' is reasonable.

BTW, I like to reverse the order of constraints and WITH options in
column definitions (2), but I could not solve shift/reduce errors
-- it might conflict with "PRIMARY KEY WITH (index-parameters)".

> - sepgsql_template1_getcon -> pg_get_template1_secon
> - sepgsql_database_getcon -> pg_get_database_secon

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

> > * It uses dedicated 'SExxx' error codes, but I think they should belong to
> > the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501).
> I already uses predefined error code, if exist.

What I meant was: there are no problem to add new error codes for SE-PgSQL,
but I think the values of the codes should be '42xxx' because those errors
are still "Class 42 - Access Rule Violation" from the view of users.

> > ==== Internal structures ====
> > * Are the security labels enough stable?
> > We store security labels as text for each object and column.
>
> If the security labels get invalid due to the modification of SELinux
> configuration or other reasons, it considers the database objects are
> unlabeled.

I believe you have a plan to add row-level security checking in the future
version. Do you have some documentation about how to implement security
context for each row? I'm worrying about the on-disk representation.
Security labels stored in text format takes 20-40 bytes per row. It is not
negligibly-small, and might be hard to be treated because of variable-length.

We store OIDs for each row at the end of tuple header. If we also
store securty labels in the same way, will we need some kinds of
"securty label to OID" converter in the future?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

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

If we put "SECURITY CONTEXT" clause prior to the column constraints,
there are no syntax conflicts. However, it seems to me not intuitive.

like, CREATE TABLE tbl (col int SECURITY CONTEXT '...' NOT NULL);

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

Instead, what is your opinion for the syntax?

CREATE TABLE tbl (...) SECURITY CONTEXT ('label', col='label', ...);

When "col=" is omitted, it means an explicit security context of the
new table. Otherwise, it means an explicit one of the given column.

And, for consistency,

CREATE DATABASE dbname SECURITY CONTEXT ('label');
CREATE SCHEMA scname SECURITY CONTEXT ('label');

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

They have different purposes.

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

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

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

Ahh, OK. I'll fix it.

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

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

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

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

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

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

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

I also think ERRCODE_INVALID_SECURITY_CONTEXT is suitable for the Access
Rule Violation class ('44xxx').

However, it seems to me ERRCODE_SELINUX_INTERNAL_ERROR should be moved
to the System Error class ('58xxx'), because it will be raised due to
the problem on communicating with SELinux, not access violations.

And, we may be able to remove ERRCODE_SELINUX_AUDIT_LOG, because audit
logs are generated on access violation events (in most case, if security
policy is right), so ERRCODE_INSUFFICIENT_PRIVILEGE might be suitable
to call ereport(LOG, ...) with an audit log message.

Isn't it strange in manner?

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

KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:

> >>> ==== Internal structures ====
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog
>
> In SELinux model, massive number of objects shares a limited number of
> security context (e.g more than 100 tables may have a same one), this
> design (it stores "security label OID" within the tuple header) is well
> suitable for database objects.

What plan do you have for system columns added by the patch
(datsecon, nspsecon, relsecon, etc) after we have securty_id
system column? Will we have duplicated features then?

Even if system tables don't use security_id columns, should the data type
of *secon be oid instead of text? I think pg_security described in the wiki
page is useful even if we only have object-level security.
How about adding pg_security and changing the type of *secon to oid?

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

Itagaki Takahiro wrote:
> KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> wrote:
>
>>>>> ==== Internal structures ====
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture#Interaction_between_pg_security_system_catalog
>>
>> In SELinux model, massive number of objects shares a limited number of
>> security context (e.g more than 100 tables may have a same one), this
>> design (it stores "security label OID" within the tuple header) is well
>> suitable for database objects.
>
> What plan do you have for system columns added by the patch
> (datsecon, nspsecon, relsecon, etc) after we have securty_id
> system column? Will we have duplicated features then?

In my plan, these fields will be removed when we add security system
column support.

> Even if system tables don't use security_id columns, should the data type
> of *secon be oid instead of text? I think pg_security described in the wiki
> page is useful even if we only have object-level security.
> How about adding pg_security and changing the type of *secon to oid?

The reason why the current version stores security context in plain
text is to minimize the scale of changeset as I have been pointed out
many times for a long time. :(
The pg_security catalog support requires about additional 1KL to the
current patch. It seems to me it goes against to the previous suggestions.

-- keep it smaller, and step-by-step enhancement

BTW, If you don't have any complaints about new syntax in CREATE TABLE
statement, I'll revise the patch soon.

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

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

I think we're getting ahead of ourselves talking about row-level
security at this point, but FWIW I have a lot of concerns about how
the previous version of this feature was designed. In particular, I
think we should set up row-level security in a way that (1) allows it
to be used for purposes other than SE-Linux and (2) allows
row-filtering to take advantage of indices. If I have a table with a
million rows, but only rights to see 100 of them, the system
administrator should be able to define an index that will allow the
100 I can see to be fetched via a bitmap-index scan rather than a
seq-scan with a probe for every row.

...Robert

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> -- keep it smaller, and step-by-step enhancement

I'd prefer "smaller concept" rather than "smaller patch".

I think the philosophy of SE-PgSQL itself is ok,
but there are some issues in the design and implementation:

==== No interaction with existing features ====
* SE-PgSQL injects security-context-based access control, but there are
no interaction between it and the existing role-based access control.

* SE-PgSQL introduces concept of "security context", but there are
no interaction between it and the existing context-related features.
(ex. pg_hba.conf and Application name patch)

This is just an idea, but how about implementing context-based access
control based on role-based ACL? We will not use security context directly
for access control, but it forbid to use ROLEs in some conditions.
An example of implementation image is:

=# ALTER ROLE role VALID ON SECURITY CONTEXT '...'

For example, this could allow us to modify rows only with a particular
application, only from particular machine, and only in particular hour.
Since we've already supported object- and column-level ACL, I think
we can the same capability of the patch using security-context-to-role
mapper. Or, is it not ideal in the policy of SELinux?

==== Postgres is not prepared to receive SE-PgSQL ====
We depend on superuser too heavily. As KaiGai-san mentioned, we use
"if (superuser())" instead of ACL in some places. It is a bad manner.
We should centralize access control in one module (maybe aclcheck.c),
and SE-PgSQL should be implemented only in the module.

If possible, it might be good for SE-PgSQL to replace all of the
role-based access control layer in postgres because it is hard for
users to maintain both Postgres ROLEs and SELinux settings consistently.
Do we need pluggable ACL layer before accepting SE-PgSQL?

==== Need to reconsider row-level security control ====
Row-level security control is excluded from the patch, but we'd better
also considering it at first. You mentioned as:

> In SELinux model, massive number of objects shares a limited number of
> security context (e.g more than 100 tables may have a same one)

but I'm not sure what application do you suppose. For example,
if we protect web application from SQL injection attacks, the
password column for each row can be read only from the end user
represented by the row. The number of security labels will be same
as the number of end users (= rows).

==== Actual benefits of SE-PgSQL ====
SE-PgSQL will be committed step-by-step -- but could you explain which step
can solve which problem in the real world? Imagine that SQL injections,
measure for SOX Act, divulgation of personal information, .... They are
security holes in terms of a whole application, but not a hole in terms of
database, because database cannot always distinguish between legal and
illegal data access (ex. correction of wrong data vs. rigging of benefits).

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

Itagaki Takahiro wrote:
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> -- keep it smaller, and step-by-step enhancement
>
> I'd prefer "smaller concept" rather than "smaller patch".

Its difference is unclear for me.

In this CF, I separated most of separatable concepts to reduce
size of the patch, as follows:
- No access controls except for databases, schemas, tables and columns
- No row-level access control granurality
- No security OID and text translation
- No access control decision cache

Needless to say, these feature can be added later, step-by-step.
But the core of SE-PgSQL is access control based on the SELinux policy.
It is an atomic feature, so unseparatable.

> ==== No interaction with existing features ====
> * SE-PgSQL injects security-context-based access control, but there are
> no interaction between it and the existing role-based access control.

If the interaction means restriction of available pairs between
a certain database role and a certain security context of the
client, it may be available as I followed on the next section.

However, SELinux accept only security context as an identifiers
of processes, files, tables and so on. If you mention to consider
database role identifier in access control decision, it is not
possible.

> * SE-PgSQL introduces concept of "security context", but there are
> no interaction between it and the existing context-related features.
> (ex. pg_hba.conf and Application name patch)
>
> This is just an idea, but how about implementing context-based access
> control based on role-based ACL? We will not use security context directly
> for access control, but it forbid to use ROLEs in some conditions.
> An example of implementation image is:
>
> =# ALTER ROLE role VALID ON SECURITY CONTEXT '...'
>
> For example, this could allow us to modify rows only with a particular
> application, only from particular machine, and only in particular hour.
> Since we've already supported object- and column-level ACL, I think
> we can the same capability of the patch using security-context-to-role
> mapper. Or, is it not ideal in the policy of SELinux?

Basically, it is not bad idea to restrict available database roles by
the security context of the client.
However, we need to revise the concept a bit.

Please remind its principle. SE-PgSQL applies all the its access controls
according to the security policy of SELinux.
SELinux defines all the access control rules as a relationship between
a couple of security contexts.

So, this idea can be rewritten as follows:

1. add a security context to pg_authid system column
2. add db_role object class in the security policy
(It needs discussion in the SELinux community)
3. It checks db_role:{loginas} permission between the client and
the security context of the db_authid entry.

For example, if the security policy allows "system_u:system_r:httpd_t:s0"
(a typical web server) domain to login as a database role labeled as
"system_u:object_r:web_role_t:s0", we can assign this context on a certain
database role to be performs as web users.

ALTER ROLE role SECURITY CONTEXT ( 'system_u:object_r:web_role_t:s0' );

Please note that I basically agree to implement this relationshipt,
but it can be implemented as an incremental patch, as long as the
core feature is merged first.

> ==== Postgres is not prepared to receive SE-PgSQL ====
> We depend on superuser too heavily. As KaiGai-san mentioned, we use
> "if (superuser())" instead of ACL in some places. It is a bad manner.
> We should centralize access control in one module (maybe aclcheck.c),
> and SE-PgSQL should be implemented only in the module.
>
> If possible, it might be good for SE-PgSQL to replace all of the
> role-based access control layer in postgres because it is hard for
> users to maintain both Postgres ROLEs and SELinux settings consistently.
> Do we need pluggable ACL layer before accepting SE-PgSQL?

I already tried this approach in the commit fest#2.
But it was a big failure. :(

I don't think it is a right direction.

In addition, former cases (SELinux, X-window, ...) does not integrate
its default access control stuff and the optional access controls.

> ==== Need to reconsider row-level security control ====
> Row-level security control is excluded from the patch, but we'd better
> also considering it at first. You mentioned as:
>
>> In SELinux model, massive number of objects shares a limited number of
>> security context (e.g more than 100 tables may have a same one)
>
> but I'm not sure what application do you suppose. For example,
> if we protect web application from SQL injection attacks, the
> password column for each row can be read only from the end user
> represented by the row. The number of security labels will be same
> as the number of end users (= rows).

I need to admit the current proposal is a "lite" version, so some of
functionality may be lack.

For example, see the page.24 of this slids:
http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf

It assigns a certain security context on web-applications for each
virtual host. In this example, a web-application once labeled as "blue"
can never access both of filesystem objects and database objects (such
as tables) labeled as other colors. SELinux performs as a logical wall
to separate individual domains.
Nowadays, we can often see such a multi-tenant system.

I'd like you to understand that I separated most of separatable features
as a result of the previous discussions, such as row-level granurality,
access control decision cache, translater between security OID and text
and so on.

> ==== Actual benefits of SE-PgSQL ====
> SE-PgSQL will be committed step-by-step -- but could you explain which step
> can solve which problem in the real world? Imagine that SQL injections,
> measure for SOX Act, divulgation of personal information, .... They are
> security holes in terms of a whole application, but not a hole in terms of
> database, because database cannot always distinguish between legal and
> illegal data access (ex. correction of wrong data vs. rigging of benefits).

Good question. The hardness to fix all the security holes in application
is the original motivation of reference monitor model (it is a conceptual
design in 80's security reserch. SELinux and other MAC system is on the
genealogy).

Please imagine the reason why SELinux applies its access control policy
on the accesses to system resources via system-calls.

If we have to fix all the application bugs, it looks like a endless-war.
The number of strategic points to be checked are infinite in fact.
However, all the application has to use system-calls to access system
resources such as files, networks, etc. It means we can aquire any
accesses without exceptions with hooks in operating system, even if
violated accesses are not bugs in operating system.

The operating system also cannot distinguish whether the given access
is actually a licit one, or not. But it prevent violated access in the
outline.
For example, when a user tries to write a file, SELinux cannot know
whether the contents is right or not. But if a "unclassified" user
tries to write something on a "classified" file, SELinux will prevent
this request independent from the correctness of the contents.

Please note that SELinux/SE-PgSQL never deny existing access control
model. They have their own purpose and whorth, we never deny it.

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

On Thu, Nov 26, 2009 at 11:15:46AM +0900, Itagaki Takahiro wrote:
> ==== No interaction with existing features ====
> * SE-PgSQL injects security-context-based access control, but there are
> no interaction between it and the existing role-based access control.

And there shouldn't be, I think. SE-PgSQL is MAC which means that what
someone can access is configured elsewhere. This example is
non-sensical:

> =# ALTER ROLE role VALID ON SECURITY CONTEXT '...'

When someone logs in they have a security context and what they can
access is then decided. You can't reconfigure what someone has access
to with anything within the DB (other than label changes), the SE-PgSQL
rules are elsewhere. That's what "Mandatory" refers to.

> but I'm not sure what application do you suppose. For example,
> if we protect web application from SQL injection attacks, the
> password column for each row can be read only from the end user
> represented by the row. The number of security labels will be same
> as the number of end users (= rows).

This example is also strange: the program that needs to read the
password need to be able to see all rows because by definition the user
cannot be logged in yet. After you login there is no need to be able to
read your own password. So column-access control is fine here.

And even if there are lots of contexts, so what? Security is not free,
but given SE-PgSQL is in use in the real world, clearly people think
the tradeoffs are worth it.

Finally, this is not about protection against SQL injection, it's protection
against people in Sales reading data belonging to Finance.

> ==== Actual benefits of SE-PgSQL ====
> SE-PgSQL will be committed step-by-step -- but could you explain which step
> can solve which problem in the real world? Imagine that SQL injections,
> measure for SOX Act, divulgation of personal information, .... They are
> security holes in terms of a whole application, but not a hole in terms of
> database, because database cannot always distinguish between legal and
> illegal data access (ex. correction of wrong data vs. rigging of benefits).

As far as I can tell, just about all the interesting cases are for
row-level security. While MAC on tables and columns will be
interesting, my guess the real uptake will be when row-level control is
in.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Itagaki Takahiro wrote:
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> -- keep it smaller, and step-by-step enhancement
>
> I'd prefer "smaller concept" rather than "smaller patch".

For the last a few days, I've talked with Itagaki-san off list to make clear
where is the point of his suggestion.

In summary, it was similar approach with what I already proposed in the CF#2,
but rejected.

During the first commit-fest of v8.5 development cycle, Stephen Frost suggested
to rework the default PG's access controls to host other optional security
features, not only the default one.
Then, I submitted a large patch titled as "Reworks for Access Controls",
but it contained 3.5KL of changeset on the core routines, and 4KL of new codes
into "src/backend/security/*" except for documentations and testcases.
Then, this approach was rejected (not "returned with feedback") due to the scale
and complexity.

After the fest, we discussed the direction to implement SE-PgSQL.
Basically, it needs to keep the changeset small, and the rest of features (such
as row-level granurality, access control decision cache, ...) shoule be added
step-by-step consistently, according to the suggestion in the v8.4 development
cycle. Heikki Linnakangas also suggested we need developer documentation which
introduces SE-PgSQL compliant permission checks and specification of security
hooks, after the reworks are rejected.

So, I boldly removed most of the features from SE-PgSQL except for its core
functionalities, and added developer documentation (README) and widespread
source code comments to introduce the implementations instead.
In the result, the current proposal is near to naked one.
- No access controls except for database, schema, table and column.
- No row-level granularity in access controls.
- No access control decision chache.
- No security OID within HeapTupleHeader.

I believe the current patch is designed according to the past suggestions.
However, his suggestion seems to me backing to the rejected approach again.

I've been torn between the past suggestions and his suggestion.
So, I asked him to get off reviewing the patch, because of the deadlock in
the development process. At the current moment, I'd like to respect
suggestions in the past discussions more.

Thanks for paying your efforts in spite of differences in opinions.
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

KaiGai Kohei wrote:
> In summary, it was similar approach with what I already proposed in the CF#2,
> but rejected.
>
> During the first commit-fest of v8.5 development cycle, Stephen Frost suggested
> to rework the default PG's access controls to host other optional security
> features, not only the default one.
> Then, I submitted a large patch titled as "Reworks for Access Controls",
> but it contained 3.5KL of changeset on the core routines, and 4KL of new codes
> into "src/backend/security/*" except for documentations and testcases.
> Then, this approach was rejected (not "returned with feedback") due to the scale
> and complexity.
>
> After the fest, we discussed the direction to implement SE-PgSQL.
> Basically, it needs to keep the changeset small, and the rest of features (such
> as row-level granurality, access control decision cache, ...) shoule be added
> step-by-step consistently, according to the suggestion in the v8.4 development
> cycle. Heikki Linnakangas also suggested we need developer documentation which
> introduces SE-PgSQL compliant permission checks and specification of security
> hooks, after the reworks are rejected.
>
> So, I boldly removed most of the features from SE-PgSQL except for its core
> functionalities, and added developer documentation (README) and widespread
> source code comments to introduce the implementations instead.
> In the result, the current proposal is near to naked one.
> - No access controls except for database, schema, table and column.
> - No row-level granularity in access controls.
> - No access control decision chache.
> - No security OID within HeapTupleHeader.
>
> I believe the current patch is designed according to the past suggestions.

Agreed. The patch is exactly what I was hoping to see:

o only covers existing Postgres ACLs
o has both user and developer documentation
o includes regression tests
o main code impact is minimal

Now, if this is applied, we might then move forward with implementing
SE-Linux specific features like mandatory access control (MAC) and
row-level security.

In terms of review, the patch is 13k lines, but most of that is
documentation, se-linux-specific files, system catalog adjustments, and
regression tests.

Also, I attended KaiGai's talk in Tokyo where he explained that managing
permission at the operating system level, the web server level (via
.htaccess and htpasswd), and at the database level is confusing, and
having a single permission system has benefits.

The number of revisions and adjustments KaiGai has done since the
original SE-PostgreSQL patch is amazing and certainly gives me
confidence that he will be around to help in case there are any problems
in the future.

So, one big problem is that no one has agreed to review it, partly or
probably because few developers understand the SE-Linux API, and many
people who have used SE-Linux have been confused by it.

I think I could review this if I could team up with someone to help me,
ideally someone on instant message (IM) and perhaps using SE-Linux.

I think the big question is whether this feature (mappming SE-Linux
permissions to existing Postgres permissions) has an acceptable code
impact. Of course we might be adding things later, but at this stage is
this something we can apply?

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

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

On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote:
> KaiGai Kohei wrote:
> > In summary, it was similar approach with what I already proposed
> > in the CF#2, but rejected.
> >
> > During the first commit-fest of v8.5 development cycle, Stephen
> > Frost suggested to rework the default PG's access controls to host
> > other optional security features, not only the default one. Then,
> > I submitted a large patch titled as "Reworks for Access Controls",
> > but it contained 3.5KL of changeset on the core routines, and 4KL
> > of new codes into "src/backend/security/*" except for
> > documentations and testcases. Then, this approach was rejected
> > (not "returned with feedback") due to the scale and complexity.
> >
> > After the fest, we discussed the direction to implement SE-PgSQL.
> > Basically, it needs to keep the changeset small, and the rest of
> > features (such as row-level granurality, access control decision
> > cache, ...) shoule be added step-by-step consistently, according
> > to the suggestion in the v8.4 development cycle. Heikki
> > Linnakangas also suggested we need developer documentation which
> > introduces SE-PgSQL compliant permission checks and specification
> > of security hooks, after the reworks are rejected.
> >
> > So, I boldly removed most of the features from SE-PgSQL except for its core
> > functionalities, and added developer documentation (README) and widespread
> > source code comments to introduce the implementations instead.
> > In the result, the current proposal is near to naked one.
> > - No access controls except for database, schema, table and column.
> > - No row-level granularity in access controls.
> > - No access control decision chache.
> > - No security OID within HeapTupleHeader.
> >
> > I believe the current patch is designed according to the past suggestions.
>
> Agreed. The patch is exactly what I was hoping to see:
>
> o only covers existing Postgres ACLs
> o has both user and developer documentation
> o includes regression tests
> o main code impact is minimal

This patch addresses points 1-3 of Andrew Sullivan's post here:
http://archives.postgresql.org/pgsql-hackers/2008-10/msg00388.php

Left out is point 4, namely whether it's possible to map metadata
access controls can do this completely, and if so, whether this patch
implements such a mapping.

This is totally separate from the really important question of whether
SE-Linux has a future, and another about whether, if SE-Linux has a
future, PostgreSQL needs to go there.

All that aside, there is an excellent economic reason why a
proprietary product might need to follow a dead-end technology, namely
increasing shareholder value due to one or more large, long-term
deals.

PostgreSQL doesn't have this motive, although some of the proprietary
forks may well.

Can we see about Andrew Sullivan's point 4? Or is it more important
to address the "do we want to" question first?

Whatever order we take them in, we do need to address both.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> In summary, it was similar approach with what I already proposed in the CF#2,
>> but rejected.
>>
>> During the first commit-fest of v8.5 development cycle, Stephen Frost suggested
>> to rework the default PG's access controls to host other optional security
>> features, not only the default one.
>> Then, I submitted a large patch titled as "Reworks for Access Controls",
>> but it contained 3.5KL of changeset on the core routines, and 4KL of new codes
>> into "src/backend/security/*" except for documentations and testcases.
>> Then, this approach was rejected (not "returned with feedback") due to the scale
>> and complexity.
>>
>> After the fest, we discussed the direction to implement SE-PgSQL.
>> Basically, it needs to keep the changeset small, and the rest of features (such
>> as row-level granurality, access control decision cache, ...) shoule be added
>> step-by-step consistently, according to the suggestion in the v8.4 development
>> cycle. Heikki Linnakangas also suggested we need developer documentation which
>> introduces SE-PgSQL compliant permission checks and specification of security
>> hooks, after the reworks are rejected.
>>
>> So, I boldly removed most of the features from SE-PgSQL except for its core
>> functionalities, and added developer documentation (README) and widespread
>> source code comments to introduce the implementations instead.
>> In the result, the current proposal is near to naked one.
>> - No access controls except for database, schema, table and column.
>> - No row-level granularity in access controls.
>> - No access control decision chache.
>> - No security OID within HeapTupleHeader.
>>
>> I believe the current patch is designed according to the past suggestions.
>
> Agreed. The patch is exactly what I was hoping to see:
>
> o only covers existing Postgres ACLs
> o has both user and developer documentation
> o includes regression tests
> o main code impact is minimal
>
> Now, if this is applied, we might then move forward with implementing
> SE-Linux specific features like mandatory access control (MAC) and
> row-level security.
>
> In terms of review, the patch is 13k lines, but most of that is
> documentation, se-linux-specific files, system catalog adjustments, and
> regression tests.
>
> Also, I attended KaiGai's talk in Tokyo where he explained that managing
> permission at the operating system level, the web server level (via
> .htaccess and htpasswd), and at the database level is confusing, and
> having a single permission system has benefits.
>
> The number of revisions and adjustments KaiGai has done since the
> original SE-PostgreSQL patch is amazing and certainly gives me
> confidence that he will be around to help in case there are any problems
> in the future.
>
> So, one big problem is that no one has agreed to review it, partly or
> probably because few developers understand the SE-Linux API, and many
> people who have used SE-Linux have been confused by it.
>
> I think I could review this if I could team up with someone to help me,
> ideally someone on instant message (IM) and perhaps using SE-Linux.

I think some of SELinux developers (including me) can help you to review
the code. They are maintaining both of the kernel and libraries (APIs).
I'll call for them to help reviewing.

BTW, I can use skype messanger in my home, and IRC may be available in office.

> I think the big question is whether this feature (mappming SE-Linux
> permissions to existing Postgres permissions) has an acceptable code
> impact. Of course we might be adding things later, but at this stage is
> this something we can apply?

It needs to deploy a set of hooks on the strategic points of the core
PostgreSQL codes, and rest of steps (such as computing a default security
context and making an access control decision) are done in the SE-PgSQL
specific files.
These hooks are designed not to prevent anything when SE-PgSQL is disabled.

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

David Fetter wrote:
> On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote:
>> KaiGai Kohei wrote:
>>> In summary, it was similar approach with what I already proposed
>>> in the CF#2, but rejected.
>>>
>>> During the first commit-fest of v8.5 development cycle, Stephen
>>> Frost suggested to rework the default PG's access controls to host
>>> other optional security features, not only the default one. Then,
>>> I submitted a large patch titled as "Reworks for Access Controls",
>>> but it contained 3.5KL of changeset on the core routines, and 4KL
>>> of new codes into "src/backend/security/*" except for
>>> documentations and testcases. Then, this approach was rejected
>>> (not "returned with feedback") due to the scale and complexity.
>>>
>>> After the fest, we discussed the direction to implement SE-PgSQL.
>>> Basically, it needs to keep the changeset small, and the rest of
>>> features (such as row-level granurality, access control decision
>>> cache, ...) shoule be added step-by-step consistently, according
>>> to the suggestion in the v8.4 development cycle. Heikki
>>> Linnakangas also suggested we need developer documentation which
>>> introduces SE-PgSQL compliant permission checks and specification
>>> of security hooks, after the reworks are rejected.
>>>
>>> So, I boldly removed most of the features from SE-PgSQL except for its core
>>> functionalities, and added developer documentation (README) and widespread
>>> source code comments to introduce the implementations instead.
>>> In the result, the current proposal is near to naked one.
>>> - No access controls except for database, schema, table and column.
>>> - No row-level granularity in access controls.
>>> - No access control decision chache.
>>> - No security OID within HeapTupleHeader.
>>>
>>> I believe the current patch is designed according to the past suggestions.
>> Agreed. The patch is exactly what I was hoping to see:
>>
>> o only covers existing Postgres ACLs
>> o has both user and developer documentation
>> o includes regression tests
>> o main code impact is minimal
>
> This patch addresses points 1-3 of Andrew Sullivan's post here:
> http://archives.postgresql.org/pgsql-hackers/2008-10/msg00388.php
>
> Left out is point 4, namely whether it's possible to map metadata
> access controls can do this completely, and if so, whether this patch
> implements such a mapping.

I'm not clear what means the metadata level access controls here.

If you talk about permissions when we create/alter/drop a certain database
obejct, the existing PG model also checks its permission. These operations
are equivalent to modify metadata of database objects.
And, SE-PgSQL also checks its permissions on modification of metadata.

We can refer the metadata of the database object using SELECT on the system
catalogs typically. In this case, we need row-level granularity because
individual tuples mean metadata of the database object. So, we don't implement
permission checks of references to metadata in this version.

I introduced it on the README file as follows:

| o getattr (not implemented yet)
|
| It is checked when a client read properties of database object.
|
| Typically, it is required on scanning database objects within system catalogs,
| such as "SELECT * FROM pg_class". Because this check requires row-level access
| control facilities, it is not implemented yet in this version.
|
| Note that no need to check this permission, unless fetched properties are
| consumed internally without returning to clients. For example, catcache stuff
| provides system internal stuff an easy way to refer system catalog. It is used
| to implement backend routines, and fetched properties are not returned to the
| client in normal way, so we don't check this permission here.

> This is totally separate from the really important question of whether
> SE-Linux has a future, and another about whether, if SE-Linux has a
> future, PostgreSQL needs to go there.
>
> All that aside, there is an excellent economic reason why a
> proprietary product might need to follow a dead-end technology, namely
> increasing shareholder value due to one or more large, long-term
> deals.
>
> PostgreSQL doesn't have this motive, although some of the proprietary
> forks may well.
>
> Can we see about Andrew Sullivan's point 4? Or is it more important
> to address the "do we want to" question first?
>
> Whatever order we take them in, we do need to address both.

As Bruce mentioned, our big motivation is improvement of web-system's
security. However, most of security burden tend to concentrate to the
quality of web applications, because it tends to share privileges on
OS/DB for all the user's requests.
In other word, correctness of the system depends on whether every
applications are bug-free, or not. But we know it is difficult to
keep them bug-free. :(

Nowadays, we can often see a web server which host multiple tenants
in a single daemon. For example, one is assigned to the division-X,
and the other is assigned to the division-Y, ...
In this case, it is worthful to prevent a (buggy) web-application to
access resources labeled as an other division independent from the
way to store information assets (either filesystem or database).

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

> This is totally separate from the really important question of whether
> SE-Linux has a future, and another about whether, if SE-Linux has a
> future, PostgreSQL needs to go there.

If the hooks are generic enough that the could potentially be adapted to
other security frameworks, yes. The need to have cohesive centralized
systems permissions management hasn't gone away, whatever anyone thinks
of the SE-linux implementation.

That's why I was hoping to have the TrustedSolaris folks working on
this, but we've pretty much lost access to them.

--Josh Berkus

On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:

> This is totally separate from the really important question of whether
> SE-Linux has a future, and another about whether, if SE-Linux has a
> future, PostgreSQL needs to go there.

Why would we think that it doesn't? Maybe I haven't been following as
much as I should but as I understand it, SE-Linux is pretty much the
defacto policy framework for Linux. Has that changed?

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
>> This is totally separate from the really important question of whether
>> SE-Linux has a future, and another about whether, if SE-Linux has a
>> future, PostgreSQL needs to go there.

> Why would we think that it doesn't?

Have you noticed anyone except Red Hat taking it seriously?

I work for Red Hat and have drunk a reasonable amount of the SELinux
koolaid, but I can't help observing that it's had very limited uptake
outside Red Hat. It's not clear that there are many people who find
it a cost-effective solution to their problems. As for the number of
people prepared to write custom policy for it --- which would be
required to use it effectively for almost any PG application ---
I could probably hold a house party for all of them and not break a
sweat serving drinks.

regards, tom lane

On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> > On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
> >> This is totally separate from the really important question of whether
> >> SE-Linux has a future, and another about whether, if SE-Linux has a
> >> future, PostgreSQL needs to go there.
>
> > Why would we think that it doesn't?
>
> Have you noticed anyone except Red Hat taking it seriously?

I just did a little research and it appears the other two big names in
this world (Novel and Ubuntu) are using something called App Armor.

>
> I work for Red Hat and have drunk a reasonable amount of the SELinux
> koolaid, but I can't help observing that it's had very limited uptake
> outside Red Hat. It's not clear that there are many people who find
> it a cost-effective solution to their problems. As for the number of
> people prepared to write custom policy for it --- which would be
> required to use it effectively for almost any PG application ---
> I could probably hold a house party for all of them and not break a
> sweat serving drinks.

Your argument certainly holds weight. The only thing I would suggest
outside of that is... it may only be Red Hat but that is a darn big hat
in Linux enterprise space.

Sincerely,

Joshua D. Drake

>
> regards, tom lane
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander

Josh Berkus wrote:
>> This is totally separate from the really important question of whether
>> SE-Linux has a future, and another about whether, if SE-Linux has a
>> future, PostgreSQL needs to go there.
>
> If the hooks are generic enough that the could potentially be adapted to
> other security frameworks, yes. The need to have cohesive centralized
> systems permissions management hasn't gone away, whatever anyone thinks
> of the SE-linux implementation.

In history, most of MAC feature have a common origin that was a research
in US military, so they have similar comcepts (such as security label,
a centralized security policy, ...) commonly.

It was the reason why I proposed PGACE framework for generic MAC features
at the earlier suggestion in v8.4 development cycle.
(Note that it had gone to separate unnecessary complexity now.)
As long as user can select his option, basically, I think it is preferable
to support multiple security models, not only SELinux.

As Linux (and also X-window) allows to host multiple MAC feature on a set
of common hooks, it is not an incorrect approach.
(Note that DAC has different origin from MAC, so we shall need a great
efforts to integrate them. My trial in CF#2 shows this failure.)

> That's why I was hoping to have the TrustedSolaris folks working on
> this, but we've pretty much lost access to them.

We can understand the current circumstance at Sun...

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

Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
>>> This is totally separate from the really important question of whether
>>> SE-Linux has a future, and another about whether, if SE-Linux has a
>>> future, PostgreSQL needs to go there.
>
>> Why would we think that it doesn't?
>
> Have you noticed anyone except Red Hat taking it seriously?
>
> I work for Red Hat and have drunk a reasonable amount of the SELinux
> koolaid, but I can't help observing that it's had very limited uptake
> outside Red Hat. It's not clear that there are many people who find
> it a cost-effective solution to their problems. As for the number of
> people prepared to write custom policy for it --- which would be
> required to use it effectively for almost any PG application ---
> I could probably hold a house party for all of them and not break a
> sweat serving drinks.

If you concerned about SELinux support may not drive explosive growth
in the number of PostgreSQL users, it is correct. It focuses on the
people who concerned about system security including RDBMS.
It is indeed a niche. All the people does not store their classified
information within databases. But, it is also a fact there are certain
demands, not limited to existing SELinux and PostgreSQL users.
("Synergetic effect" is a correct English expression?)

Now PostgreSQL has various kind of optional features. I think these are
not always valuable for all the people, but it is valuable for users who
enabled the features. SELinux support is not a special case.

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

Joshua D. Drake wrote:
> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
>>>> This is totally separate from the really important question of whether
>>>> SE-Linux has a future, and another about whether, if SE-Linux has a
>>>> future, PostgreSQL needs to go there.
>>> Why would we think that it doesn't?
>> Have you noticed anyone except Red Hat taking it seriously?
>
> I just did a little research and it appears the other two big names in
> this world (Novel and Ubuntu) are using something called App Armor.

As far as I can see, SUSE, Ubuntu and Debian provide SELinux option.
But they are more conservative than RedHat/Fedora, because it is not
enabled in the default installation.

I don't think it is unpreferable decision. Users can choose the option
by themself according to requirements in the system.

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

KaiGai Kohei wrote:

===
Joshua D. Drake wrote:
> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
>>>> This is totally separate from the really important question of whether
>>>> SE-Linux has a future, and another about whether, if SE-Linux has a
>>>> future, PostgreSQL needs to go there.
>>> Why would we think that it doesn't?
>> Have you noticed anyone except Red Hat taking it seriously?
>
> I just did a little research and it appears the other two big names in
> this world (Novel and Ubuntu) are using something called App Armor.

As far as I can see, SUSE, Ubuntu and Debian provide SELinux option.
But they are more conservative than RedHat/Fedora, because it is not
enabled in the default installation.

I don't think it is unpreferable decision. Users can choose the option
by themself according to requirements in the system.

===

How much of the work currently at hand might be applicable to other security models ? Would this be useful groundwork for anyone who wanted to implement other frameworks in terms of hooks, cleanup of existing code, etc. ?

Greg W.

Greg Williamson wrote:
> As far as I can see, SUSE, Ubuntu and Debian provide SELinux
> option. But they are more conservative than RedHat/Fedora,
> because it is not enabled in the default installation.
>
> I don't think it is unpreferable decision. Users can choose the
> option by themself according to requirements in the system.
>
> ===
>
> How much of the work currently at hand might be applicable to
> other security models ? Would this be useful groundwork for
> anyone who wanted to implement other frameworks in terms of
> hooks, cleanup of existing code, etc. ?

Yes, it would offer clear groundwork for that, and could be easily
extended. We didn't implement such a system at this stage because it
would have added additional code, but once there is demand the system
could be easily extended.

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

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

KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
> Joshua D. Drake wrote:
>> I just did a little research and it appears the other two big names in
>> this world (Novel and Ubuntu) are using something called App Armor.

> As far as I can see, SUSE, Ubuntu and Debian provide SELinux option.
> But they are more conservative than RedHat/Fedora, because it is not
> enabled in the default installation.

> I don't think it is unpreferable decision. Users can choose the option
> by themself according to requirements in the system.

Based on Red Hat's experience, it is a safe bet that not enabling
SELinux by default guarantees the feature will remain useless to the
average user. As was pointed out upthread (and I can confirm from
personal experience), it's taken *years* for Red Hat to develop the
security policy to a point where it's even marginally usable by anyone
who isn't willing to put up with a great deal of annoyance because they
have an extreme need. And that's despite having a well-defined, not too
ambitious goal for what it is they are trying to secure: for the most
part, RH's default policy doesn't try to lock down anything except
network-accessible services. SUSE and the rest of them may "have the
feature", but they don't have it in a usable form, and won't ever have
it without a much larger effort than they're making.

Even if we were to accept the SEPostgres patches lock stock and barrel
tomorrow, I don't foresee that it will ever get to the point of being
useful except to an extremely small group of users who are driven by
extreme need. Nobody else is going to have the motivation needed to
develop custom security policies, and there simply isn't any chance
of anyone developing any generally useful default policy. Red Hat's
policy has been trying to cope with cases like "which directories should
Apache be allowed to read, *given that it's running a Red-Hat-standard
configuration*?" That's far more circumscribed than any useful database
policy would be, because database applications aren't nearly that
standardized.

If SEPostgres were a small patch that wouldn't need much ongoing effort,
I might think it's reasonable to adopt it for the benefit of only a small
group of users. However, it's not small, it's not simple, and it will
not be low-maintenance. I'm afraid the cost-benefit ratio from the
project's perspective is just not reasonable.

regards, tom lane

Tom Lane wrote:
> Even if we were to accept the SEPostgres patches lock stock and barrel
> tomorrow, I don't foresee that it will ever get to the point of being
> useful except to an extremely small group of users who are driven by
> extreme need. Nobody else is going to have the motivation needed to
> develop custom security policies, and there simply isn't any chance
> of anyone developing any generally useful default policy. Red Hat's
> policy has been trying to cope with cases like "which directories should
> Apache be allowed to read, *given that it's running a Red-Hat-standard
> configuration*?" That's far more circumscribed than any useful database
> policy would be, because database applications aren't nearly that
> standardized.

Basically, it is the last option to write custom policy modules for users,
and it is not a recommendable for average users.
The default security policy contains various kind of pre-defined security
contexts, and it allows administrators to assign them dirs/files according
to their purpose. In most cases, user can complete SELinux setups with
customizations nowadays, not writing their custom policy modules.

For example, the default security policy intend to web contents are stored
in "/var/www/html" labeled as "httpd_sys_content_t" which allows web-servers
read-only access to the files. If we want to store web contents in
"/opt/html", all we have to do is:

$ chcon -R system_u:object_r:httpd_sys_content_t:s0 /opt/html

It changes the security context of the /opt/html and files under the
directory. It performs as web-contents from perspective of SELinux.

We can apply similar configuration on database objects.
For example, we want to have a read-only table from confined processes,
all we have to do is:

CREATE TABLE read_only_tbl (
x int,
y text
) SECURITY CONTEXT ('system_u:object_r:sepgsql_ro_table_t:s0');

The "sepgsql_ro_table_t" is a type which allows confined processes only
SELECT contents from the table, and it is provided by the default security
policy. We don't need to write any custom security policy in typical use
cases.

SELinux has been integrated into RedHat/Fedora since FC2.
It had a lot of matters in the early phase. For example, the default security
policy was troubled, user needed to modify the security policy and rebuild
whole of the policy, here were no custmization parameters, ...
However, these matters have been resolved for the recent years.

It seems to me your complaints based on the legacy SELinux.

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

[ Updated subject ]

We have been discussing support for SE-Linux for over a year and now
have a minimal patch submitted that maps SE-Linux permissions to
existing Postgres permissions:

patch: http://momjian.us/tmp/sepgsql-01-lite-8.5devel-r2451.patch
email: http://archives.postgresql.org/message-id/4B13856F.1090803@ak.jp.nec.com

That patch is the minimum required to support SE-Linux in some form.
The majority of the patch is documentation, regression tests, small
catalog additions, and SE-Linux-specific C files. It does add hooks
into the existing access permission functions. There is no support for
row-level permissions or mandatory access control (MAC). These were
removed to minimize code impact and might be added later.

Tom's email below highlights the lack of mainstream usage of SE-Linux
features, though it is supported by most Linux distributions. Tom's
opinion is adding support for a minimal set of SE-Linux security isn't
worth the code impact.

David Fetter felt SE-Linux was mostly a marketing/sales feature, rather
than something of general usefulness. Others feel SE-Linux is valid for
limited use cases.

I understand SE-Linux to be like Kerberos --- Kerberos provides
single-signon site authentication, while SE-Linux provides single-signon
site security credentials. While Kerberos is not useful for everyone,
SE-Linux similarly has limited adoption. Kerberos has proven to be a
key technology for sites that need it, and SE-Linux might prove to be
similar.

If we decide not to support SE-Linux, it is unlikely we will be adding
support for any other external security systems because SE-Linux has the
widest adoption.

I think the big question is whether we are ready to extend Postgres to
support additional security infrastructures.

---------------------------------------------------------------------------

Tom Lane wrote:
> KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
> > Joshua D. Drake wrote:
> >> I just did a little research and it appears the other two big names in
> >> this world (Novel and Ubuntu) are using something called App Armor.
>
> > As far as I can see, SUSE, Ubuntu and Debian provide SELinux option.
> > But they are more conservative than RedHat/Fedora, because it is not
> > enabled in the default installation.
>
> > I don't think it is unpreferable decision. Users can choose the option
> > by themself according to requirements in the system.
>
> Based on Red Hat's experience, it is a safe bet that not enabling
> SELinux by default guarantees the feature will remain useless to the
> average user. As was pointed out upthread (and I can confirm from
> personal experience), it's taken *years* for Red Hat to develop the
> security policy to a point where it's even marginally usable by anyone
> who isn't willing to put up with a great deal of annoyance because they
> have an extreme need. And that's despite having a well-defined, not too
> ambitious goal for what it is they are trying to secure: for the most
> part, RH's default policy doesn't try to lock down anything except
> network-accessible services. SUSE and the rest of them may "have the
> feature", but they don't have it in a usable form, and won't ever have
> it without a much larger effort than they're making.
>
> Even if we were to accept the SEPostgres patches lock stock and barrel
> tomorrow, I don't foresee that it will ever get to the point of being
> useful except to an extremely small group of users who are driven by
> extreme need. Nobody else is going to have the motivation needed to
> develop custom security policies, and there simply isn't any chance
> of anyone developing any generally useful default policy. Red Hat's
> policy has been trying to cope with cases like "which directories should
> Apache be allowed to read, *given that it's running a Red-Hat-standard
> configuration*?" That's far more circumscribed than any useful database
> policy would be, because database applications aren't nearly that
> standardized.
>
> If SEPostgres were a small patch that wouldn't need much ongoing effort,
> I might think it's reasonable to adopt it for the benefit of only a small
> group of users. However, it's not small, it's not simple, and it will
> not be low-maintenance. I'm afraid the cost-benefit ratio from the
> project's perspective is just not reasonable.
>
> regards, tom lane

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

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

Bruce,

> If we decide not to support SE-Linux, it is unlikely we will be adding
> support for any other external security systems because SE-Linux has the
> widest adoption.
>
> I think the big question is whether we are ready to extend Postgres to
> support additional security infrastructures.

PostgreSQL is the most security-conscious of the OSS databases, and is
widely used by certain groups (security software, military, credit card
processing) precisely because of this reputation. These folks, while
unlikely to speak up on -hackers, are interested in new/further security
features; when I was at the Pentagon 2 years ago several people there
from HS were quite interested in SE-Postgres specifically. Further,
I've been mentioning SE-Postgres in my "DB security talk" for the last
18 months and I *always* get a question about it.

So while there might not be vocal proponents for innovative/hard-core
security frameworks on this list currently, I think it will gain us some
new users. Maybe more than we expect.

When GIS was introduced to this list ten years ago it was criticized as
a marginal feature and huge and intrusive. But today it's probably 40%
of our user base, and growing far more rapidly than anything else with
Postgres. Maybe SE will be more like Rules than like GIS in the long
run, but there's no way for us to know that today.

--Josh Berkus

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> When GIS was introduced to this list ten years ago it was criticized as
> a marginal feature and huge and intrusive. But today it's probably 40%
> of our user base, and growing far more rapidly than anything else with
> Postgres. Maybe SE will be more like Rules than like GIS in the long
> run, but there's no way for us to know that today.

What we do know is that GIS could be, and was, successfully developed
outside core Postgres. It didn't need to suck away a major portion of
the effort of the core developers. So it's not a very good analogy.

In the end this is a debate about what the community should do with its
finite development resources. Maybe, if we build this thing, they will
come and we'll get so much additional contribution that it'll be a win
all around. But somehow, alleged users who won't even decloak enough
to tell us they want it don't seem like likely candidates for becoming
major contributors.

In words of one syllable: I do not care at all whether the NSA would use
Postgres, if they're not willing to come and help us build it. If we
tried to build it without their input, we'd probably not produce what
they want anyway.

regards, tom lane

On Wed, Dec 2, 2009 at 3:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>  Red Hat's
> policy has been trying to cope with cases like "which directories should
> Apache be allowed to read, *given that it's running a Red-Hat-standard
> configuration*?"  That's far more circumscribed than any useful database
> policy would be, because database applications aren't nearly that
> standardized.

Actually that does sound useful for Redhat packages which themselves
use database. So for example if I install my Redhat spam filter it
should be able to automatically run createdb and load its schema and
start using postgres as a backing store. Currently I think a lot of
packages use sqlite by default just because manual intervention is
required to set up postgres.

So I'm unclear what advantage this has for Redhat and sysadmins over
just setting up the database directly but then I'm unclear what the
advantage is for SELinux in the first place so I'm probably just not
in the target audience for it. But this seems like it would be
directly analogous. I suppose an admin would be able to delegate more
control to a new admin

--
greg

Josh Berkus wrote:
> Bruce,
>
>> If we decide not to support SE-Linux, it is unlikely we will be adding
>> support for any other external security systems because SE-Linux has the
>> widest adoption.
>>
>> I think the big question is whether we are ready to extend Postgres to
>> support additional security infrastructures.
>
> PostgreSQL is the most security-conscious of the OSS databases, and is
> widely used by certain groups (security software, military, credit card
> processing) precisely because of this reputation. These folks, while
> unlikely to speak up on -hackers, are interested in new/further security
> features; when I was at the Pentagon 2 years ago several people there
> from HS were quite interested in SE-Postgres specifically. Further,
> I've been mentioning SE-Postgres in my "DB security talk" for the last
> 18 months and I *always* get a question about it.
>
> So while there might not be vocal proponents for innovative/hard-core
> security frameworks on this list currently, I think it will gain us some
> new users. Maybe more than we expect.

Good, I also have gotten many voices, questions and requirements from
the viewpoints of enterprise users who make plans to launch their SaaS
system typically.

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

Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> When GIS was introduced to this list ten years ago it was criticized as
>> a marginal feature and huge and intrusive. But today it's probably 40%
>> of our user base, and growing far more rapidly than anything else with
>> Postgres. Maybe SE will be more like Rules than like GIS in the long
>> run, but there's no way for us to know that today.
>
> What we do know is that GIS could be, and was, successfully developed
> outside core Postgres. It didn't need to suck away a major portion of
> the effort of the core developers. So it's not a very good analogy.
>
> In the end this is a debate about what the community should do with its
> finite development resources. Maybe, if we build this thing, they will
> come and we'll get so much additional contribution that it'll be a win
> all around. But somehow, alleged users who won't even decloak enough
> to tell us they want it don't seem like likely candidates for becoming
> major contributors.
>
> In words of one syllable: I do not care at all whether the NSA would use
> Postgres, if they're not willing to come and help us build it. If we
> tried to build it without their input, we'd probably not produce what
> they want anyway.

I don't know any reputations of NSA in US, except for Hollywood often
makes them baddie in movies.

However, it is the fact SELinux is already an open source software
supported by people and corporations in multiple nations including
former communist nations, not only USA and its allied nations.

Needless to say, NEC is also a supporter to develop and maintain
SE-PgSQL feature. We believe it is a necessity feature to construct
secure platform for SaaS/Cloud computing, so my corporation has funded
to develop SE-PgSQL for more than two years.

As I noted before, if you worried about I escape anyware, it is quite
incorrect. Now I've been working to develop and integrate SE-PgSQL in
full-time.

We can also say SELinux community provides a development resource to
other OSS communities. For example, the recent version of Xorg has
SELinux support in userspace, such as SE-PgSQL, by the developer who
originally worked in SELinux community. SE-PgSQL is a similar case.
Anyway, I don't think we should build barrier between communities.

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

KaiGai Kohei wrote:.
> Needless to say, NEC is also a supporter to develop and maintain
> SE-PgSQL feature. We believe it is a necessity feature to construct
> secure platform for SaaS/Cloud computing, so my corporation has funded
> to develop SE-PgSQL for more than two years.
>
> As I noted before, if you worried about I escape anyware, it is quite
> incorrect. Now I've been working to develop and integrate SE-PgSQL in
> full-time.
>
> We can also say SELinux community provides a development resource to
> other OSS communities. For example, the recent version of Xorg has
> SELinux support in userspace, such as SE-PgSQL, by the developer who
> originally worked in SELinux community. SE-PgSQL is a similar case.
> Anyway, I don't think we should build barrier between communities.
>
>
>

I think you have been remarkably good about our caution in accepting
this. You certainly have my admiration for your patience.

What would probably help us a lot would be to know some names of large
users who want and will support this. NEC's name is a good start, but if
a few other enterprise users spoke up it would help to make the decision
a lot easier.

My own experience with SE-Linux has been fairly unfortunate - I have
tripped over it too many times and years ago adopted a practice of
turning it off whenever I could. I suspect many people have similar war
stories, and there will thus probably be quite some resistance to a
feature I accept could well be of significant use to some classes of users.

cheers

andrew

KaiGai Kohei wrote:
> Needless to say, NEC is also a supporter to develop and maintain
> SE-PgSQL feature. We believe it is a necessity feature to construct
> secure platform for SaaS/Cloud computing, so my corporation has funded
> to develop SE-PgSQL for more than two years.

Rather than "needless to say", I think this is worth elaborating on.

Knowing how companies like NEC and their customers see SELinux and
SE-PgSQL help their database projects would probably be one of the
most compelling stories for getting broader support for the feature.

Before googling "nec software" after seeing you mention
this, I knew very little about NEC's software business.
I can read some about NEC's software/database business for
NEC North America's[1] and NEC Global Services[2] but imagine
globally there's even more to it than that.

Understanding how SE-PgSQL (and presumably SE-Linux) helps
build a better SaaS/Cloud computing platform would probably
help many people support this feature more. The cloud computing
platforms I see more are ones that isolate a user's data either
at a higher application layer (like salesforce) or a lower
virtual machine layer (like amazon's elastic cloud). Is a
vision of SE-PgSQL to help cloud computing companies sell
customers access to a single underlying postgres instance,
and share selected data between each other at a row level?
Just curious.

[1] http://www.necam.com/EntSw/
[2] http://www.necgs.com/partners.php

Joshua D. Drake wrote:
> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
>>>> This is totally separate from the really important question of whether
>>>> SE-Linux has a future, and another about whether, if SE-Linux has a
>>>> future, PostgreSQL needs to go there.
>>> Why would we think that it doesn't?
>> Have you noticed anyone except Red Hat taking it seriously?
>
> I just did a little research and it appears the other two big names in
> this world (Novel and Ubuntu) are using something called App Armor.

How much of SE-PgSQL would also complement the App Armor framework?

Also, yet another MAC system called Tomoyo from NTT was merged into
the linux kernel earlier this year.

Is SE-PgSQL orthogonal and/or complimentary to all of those?

Since I see MAC features continuing to be added to operating
systems, I can certainly imagine they're important to some
customers.

Greg Stark wrote:
> So I'm unclear what advantage this has for Redhat and sysadmins over
> just setting up the database directly but then I'm unclear what the
> advantage is for SELinux in the first place so I'm probably just not
> in the target audience for it. But this seems like it would be
> directly analogous. I suppose an admin would be able to delegate more
> control to a new admin

We (security engineers) consider to coordinate access controls on
whole of the system, not only database, although it might be an
irritating wordage for pgsql-hackers.

Needless to say, database is one of the most significant software
components nowadays, but not all. From the perspective of security
administration, we want to restrict user's privileges using
a centralized basis, called security policy.

The basis needs to be independent from structures of a certain
subsystem, such as OS or DBMS. SELinux is well suitable for the
requirements in Linux.
Note that SELinux is implemented as a feature of OS in fact, but it
makes its access control decision based on only a couple of security
contexts which is a class-independent identifier.
(It is called "reference monitor" in security region.)

It is not a good idea to invent an another framework again for
whole of the system security, because many of userspace applications
already support SELinux features. It also means stuff to manage security
context of resources, not only applying additional access controls based
on SELinux policy like SE-PgSQL.
For example, "ls -Z" shows security context of files, "mv" keeps
security context of files, even if user tries to move a file across
filesystems, "tar --selinux" support backup/restore security context
of the files, ...

There are various kind of options, however, SELinux provides most
widespread support on various kind of software components.

If we would be Oracle, we may be able to provide whole of the software
components. But it is not right way in OSS community.

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

Ron Mayer wrote:
> KaiGai Kohei wrote:
>> Needless to say, NEC is also a supporter to develop and maintain
>> SE-PgSQL feature. We believe it is a necessity feature to construct
>> secure platform for SaaS/Cloud computing, so my corporation has funded
>> to develop SE-PgSQL for more than two years.
>
> Rather than "needless to say", I think this is worth elaborating on.
>
> Knowing how companies like NEC and their customers see SELinux and
> SE-PgSQL help their database projects would probably be one of the
> most compelling stories for getting broader support for the feature.
>
> Before googling "nec software" after seeing you mention
> this, I knew very little about NEC's software business.
> I can read some about NEC's software/database business for
> NEC North America's[1] and NEC Global Services[2] but imagine
> globally there's even more to it than that.

I'm talking about our future business, not existing one.

Anyway, what is important here is that out corporation makes a decision
to contribute to develop and maintain an innovative OSS project rather
than what our business works well.

> Understanding how SE-PgSQL (and presumably SE-Linux) helps
> build a better SaaS/Cloud computing platform would probably
> help many people support this feature more. The cloud computing
> platforms I see more are ones that isolate a user's data either
> at a higher application layer (like salesforce) or a lower
> virtual machine layer (like amazon's elastic cloud). Is a
> vision of SE-PgSQL to help cloud computing companies sell
> customers access to a single underlying postgres instance,
> and share selected data between each other at a row level?
> Just curious.

Basically, note than we have no magic-bullets in security region.
Any approach has its merits and demerits. It depends on users what
should be emphasized.

If we tries to separate user's information assets in the application
level (like salesforce), the code to be checked and bug-free are much
larger than a case when we enforce accesses in OS/RDBMS.
It shall make development cost to increase.

If we tries to separate user's information assets in the virtual machine
layer (like amazon), the worker-hour to maintain each virtual machines
larger than a case when we enforce accesses in OS/RDBMS layer.
It shall make maintenance cost to increase.

If we tries to separate user's information assets in the OS/RDBMS layer,
the code to be checked and bug-free are less than application level
checks, and all administrator need to do is manage a limited number of
instances.

The granularity of access controls is not a primary matter.
We can separate user's information assets in table level, not only row
level. In addition, we cat set up a part of shared tables, unlike virtual
machine approach.

I don't mean this approach it a magic-bullets, but it can be an option
for security-conscious users.

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

Ron Mayer wrote:
> Joshua D. Drake wrote:
>> On Tue, 2009-12-01 at 14:46 -0500, Tom Lane wrote:
>>> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>>>> On Mon, 2009-11-30 at 20:28 -0800, David Fetter wrote:
>>>>> This is totally separate from the really important question of whether
>>>>> SE-Linux has a future, and another about whether, if SE-Linux has a
>>>>> future, PostgreSQL needs to go there.
>>>> Why would we think that it doesn't?
>>> Have you noticed anyone except Red Hat taking it seriously?
>> I just did a little research and it appears the other two big names in
>> this world (Novel and Ubuntu) are using something called App Armor.
>
> How much of SE-PgSQL would also complement the App Armor framework?
>
> Also, yet another MAC system called Tomoyo from NTT was merged into
> the linux kernel earlier this year.
>
> Is SE-PgSQL orthogonal and/or complimentary to all of those?
>
> Since I see MAC features continuing to be added to operating
> systems, I can certainly imagine they're important to some
> customers.

Yes, nowadays, Linux has three MAC options: Linux, Smack and Tomoyo.
And AppArmor is now under discussion to merge it.

*In the current state*, our security hooks invoke SE-PgSQL routines
directly, unlike LSM framework in Linux, because it is the first
option for us, and no need to support multiple options now.
(It will simply increase the size of changeset in this stage.)

However, when the second option comes in, we can easily enhance the
security hooks to support multiple MAC framework.
The Smack also needs security label. It will be able to share facilities
to manage security context with SE-PgSQL.

I've often talked with developers of TOMOYO Linux. They currently give
higher priority to upstream all their functionalities into Linux.
But it also may be a valueable theme for them.
At least, I don't think it requires much different hook points more
than SELinux support.

AppArmor's access control model is similar to TOMOYO.

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

Andrew Dunstan wrote:
> I think you have been remarkably good about our caution in accepting
> this. You certainly have my admiration for your patience.

Agreed.

> What would probably help us a lot would be to know some names of large
> users who want and will support this. NEC's name is a good start, but if
> a few other enterprise users spoke up it would help to make the decision
> a lot easier.

I think the open questions we have now are:

o Is SE-Linux appropriate technology for Postgres?
o Does SE-Linux have a sufficient user base or potential
user base to justify the additional code?
o Can the code be maintained?

And we have some partial answers. SE-Linux seems like the most popular
of the security frameworks. There are a number of identified potential
users, though we are looking to hear about more of them. Third, KaiGai
is being paid by NEC to do this work and has shown to be extraordinarily
dedicated to this feature. He has also offered to get other SE-Linux
people involved in any patch review.

I think the PostGIS example mentioned earlier is a good one. We did
make some minor adjustments years ago to make things easier for them,
but we had the luxury of having PostGIS be able to be developed outside
of our main tree. I think with the current posted patch we have some of
that benefit in that most of the code is in SE-Linux-specific
directories, but the code outside those directories does have to be
maintained.

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

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

> In words of one syllable: I do not care at all whether the NSA would use
> Postgres, if they're not willing to come and help us build it.

There's several 2-syllable words there. ;-)

If we
> tried to build it without their input, we'd probably not produce what
> they want anyway.

Yeah, the *complete* lack of input/help from the security community
aside from the occasional "SE Linux good" posts we've gotten is
troubling. We could end up with a SQL-J.

Kaigai, you've said that you could get SELinux folks involved in the
patch review. I think it's past time that they were; please solicit them.

--Josh Berkus

On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> In words of one syllable: I do not care at all whether the NSA would use
>> Postgres, if they're not willing to come and help us build it.
>
> There's several 2-syllable words there.  ;-)
>
>  If we
>> tried to build it without their input, we'd probably not produce what
>> they want anyway.
>
> Yeah, the *complete* lack of input/help from the security community
> aside from the occasional "SE Linux good" posts we've gotten is
> troubling.  We could end up with a SQL-J.
>
> Kaigai, you've said that you could get SELinux folks involved in the
> patch review.  I think it's past time that they were; please solicit them.

Actually, we tried that already, in a previous iteration of this
discussion. Someone actually materialized and commented on a few
things. The problem, as I remember it, was that they didn't know much
about PostgreSQL, so we didn't get very far with it. Unfortunately, I
can't find the relevant email thread at the moment.

In fact, we've tried about everything with these patches. Tom
reviewed them, Bruce reviewed them, Peter reviewed them, I reviewed
them, Stephen Frost reviewed them, Heikki took at least a brief look
at them, and I think there were a few other people, too. The first
person who I can recall being relatively happy with any version of
this patch was Stephen Frost, commenting on the access control
framework that we suggested KaiGai try to separate from the main body
of the patch to break it into more managable chunks. That patch was
summarily rejected by Tom for what I believe were valid reasons. In
other words, in 18 months of trying we've yet to see something that is
close to being committable. Contrast that with Hot Standby, which
Heikki made a real shot at committing during the first CommitFest to
which it was submitted.

I think David Fetter summarized it pretty well here - the rest of the
thread is worth reading, too.

http://archives.postgresql.org/pgsql-hackers/2009-07/msg01159.php

I think the only chance of this ever getting committed is if a
committer volunteers to take ownership of it, similar to what Heikki
has done for Hot Standby and Streaming Replication. Right now, we
don't have any volunteers, and even if Tom or Heikki were interested,
I suspect it would occupy their entire attention for several
CommitFests just as HS and SR have done for Heikki. I suspect the
amount of work for SE-PostgreSQL might even be larger than for HS. If
we DON'T have a committer who is willing to own this, then I don't
think there's a choice other than giving up.

...Robert

Robert Haas wrote:
> Actually, we tried that already, in a previous iteration of this
> discussion. Someone actually materialized and commented on a few
> things. The problem, as I remember it, was that they didn't know much
> about PostgreSQL, so we didn't get very far with it. Unfortunately, I
> can't find the relevant email thread at the moment.
>
> In fact, we've tried about everything with these patches. Tom
> reviewed them, Bruce reviewed them, Peter reviewed them, I reviewed
> them, Stephen Frost reviewed them, Heikki took at least a brief look
> at them, and I think there were a few other people, too. The first
> person who I can recall being relatively happy with any version of
> this patch was Stephen Frost, commenting on the access control
> framework that we suggested KaiGai try to separate from the main body
> of the patch to break it into more managable chunks. That patch was
> summarily rejected by Tom for what I believe were valid reasons. In
> other words, in 18 months of trying we've yet to see something that is
> close to being committable. Contrast that with Hot Standby, which
> Heikki made a real shot at committing during the first CommitFest to
> which it was submitted.
>
> I think David Fetter summarized it pretty well here - the rest of the
> thread is worth reading, too.
>
> http://archives.postgresql.org/pgsql-hackers/2009-07/msg01159.php
>
> I think the only chance of this ever getting committed is if a
> committer volunteers to take ownership of it, similar to what Heikki
> has done for Hot Standby and Streaming Replication. Right now, we
> don't have any volunteers, and even if Tom or Heikki were interested,
> I suspect it would occupy their entire attention for several
> CommitFests just as HS and SR have done for Heikki. I suspect the
> amount of work for SE-PostgreSQL might even be larger than for HS. If
> we DON'T have a committer who is willing to own this, then I don't
> think there's a choice other than giving up.

I offered to review it. I was going to mostly review the parts that
impacted our existing code, and I wasn't going to be able to do a
thorough job of the SE-Linux-specific files.

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

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

On Sat, Dec 5, 2009 at 12:14 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> Actually, we tried that already, in a previous iteration of this
>> discussion.  Someone actually materialized and commented on a few
>> things.  The problem, as I remember it, was that they didn't know much
>> about PostgreSQL, so we didn't get very far with it.  Unfortunately, I
>> can't find the relevant email thread at the moment.
>>
>> In fact, we've tried about everything with these patches.  Tom
>> reviewed them, Bruce reviewed them, Peter reviewed them, I reviewed
>> them, Stephen Frost reviewed them, Heikki took at least a brief look
>> at them, and I think there were a few other people, too.  The first
>> person who I can recall being relatively happy with any version of
>> this patch was Stephen Frost, commenting on the access control
>> framework that we suggested KaiGai try to separate from the main body
>> of the patch to break it into more managable chunks.  That patch was
>> summarily rejected by Tom for what I believe were valid reasons.  In
>> other words, in 18 months of trying we've yet to see something that is
>> close to being committable.  Contrast that with Hot Standby, which
>> Heikki made a real shot at committing during the first CommitFest to
>> which it was submitted.
>>
>> I think David Fetter summarized it pretty well here - the rest of the
>> thread is worth reading, too.
>>
>> http://archives.postgresql.org/pgsql-hackers/2009-07/msg01159.php
>>
>> I think the only chance of this ever getting committed is if a
>> committer volunteers to take ownership of it, similar to what Heikki
>> has done for Hot Standby and Streaming Replication.  Right now, we
>> don't have any volunteers, and even if Tom or Heikki were interested,
>> I suspect it would occupy their entire attention for several
>> CommitFests just as HS and SR have done for Heikki.  I suspect the
>> amount of work for SE-PostgreSQL might even be larger than for HS.  If
>> we DON'T have a committer who is willing to own this, then I don't
>> think there's a choice other than giving up.
>
> I offered to review it.  I was going to mostly review the parts that
> impacted our existing code, and I wasn't going to be able to do a
> thorough job of the SE-Linux-specific files.

Review it and commit it, after making whatever modifications are
necessary? Or review it in part, leaving the final review and commit
to someone else?

I just read through the latest version of this patch and it does
appear to be in significantly better shape than the versions I read
back in July. So it might not require a Herculean feat of strength to
get this in, but I still think it's going to be a big job. There's a
lot of code here that needs to be verified and in some cases probably
cleaned up or restructured. If you're prepared to take it on, I'm not
going to speak against that, other than to say that I think you have
your work cut out for you.

...Robert

Robert Haas wrote:
> > I offered to review it. ?I was going to mostly review the parts that
> > impacted our existing code, and I wasn't going to be able to do a
> > thorough job of the SE-Linux-specific files.
>
> Review it and commit it, after making whatever modifications are
> necessary? Or review it in part, leaving the final review and commit
> to someone else?
>
> I just read through the latest version of this patch and it does
> appear to be in significantly better shape than the versions I read
> back in July. So it might not require a Herculean feat of strength to
> get this in, but I still think it's going to be a big job. There's a
> lot of code here that needs to be verified and in some cases probably
> cleaned up or restructured. If you're prepared to take it on, I'm not
> going to speak against that, other than to say that I think you have
> your work cut out for you.

This is no harder than many of the other seemingly crazy things I have
done, e.g. Win32 port, client library threading. If this is a feature
we should have, I will get it done or get others to help me complete the
task.

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

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

Robert Haas wrote:
> On Thu, Dec 3, 2009 at 5:23 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> Kaigai, you've said that you could get SELinux folks involved in the
>> patch review. I think it's past time that they were; please solicit them.
>
> Actually, we tried that already, in a previous iteration of this
> discussion. Someone actually materialized and commented on a few
> things. The problem, as I remember it, was that they didn't know much
> about PostgreSQL, so we didn't get very far with it. Unfortunately, I
> can't find the relevant email thread at the moment.

IIRC, at least a couple of the guys mentioned on the NSA's
SE-Linux page[1] participated - Joshua Brindle[2] and Chad
Sellers[3] (in addition to Kaigai/NEC who's credited on the
NSA site as well). Perhaps one or two others too - but with
common names it's hard to guess.

Links to the threads with Chad and Joshua below.

[1] http://www.nsa.gov/research/selinux/contrib.shtml
[2] http://www.google.com/search?q=site%3Aarchives.postgresql.org+brindle
[3] http://www.google.com/search?q=site%3Aarchives.postgresql.org+chad+sellers

On Sat, Dec 5, 2009 at 8:18 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> > I offered to review it. ?I was going to mostly review the parts that
>> > impacted our existing code, and I wasn't going to be able to do a
>> > thorough job of the SE-Linux-specific files.
>>
>> Review it and commit it, after making whatever modifications are
>> necessary?  Or review it in part, leaving the final review and commit
>> to someone else?
>>
>> I just read through the latest version of this patch and it does
>> appear to be in significantly better shape than the versions I read
>> back in July.  So it might not require a Herculean feat of strength to
>> get this in, but I still think it's going to be a big job.  There's a
>> lot of code here that needs to be verified and in some cases probably
>> cleaned up or restructured.  If you're prepared to take it on, I'm not
>> going to speak against that, other than to say that I think you have
>> your work cut out for you.
>
> This is no harder than many of the other seemingly crazy things I have
> done, e.g. Win32 port, client library threading.  If this is a feature
> we should have, I will get it done or get others to help me complete the
> task.

Well, I have always thought that it would be sort of a feather in our
cap to support this, which is why I've done a couple of reviews of it
in the past. I tend to agree with Tom that only a small fraction of
our users will probably want it, but then again someone's been paying
KaiGai to put a pretty hefty amount of work into this over the last
year-plus, so obviously someone not only wants the feature but wants
it merged. Within our community, I think that there have been a lot
of people who have liked the concept of this feature but very few who
have liked the patch, so there's somewhat of a disconnect between our
aspirations and our better technical judgment. Tom is a notable
exception who I believe likes neither the concept nor the patch, which
is something we may need to resolve before getting too serious about
this.

...Robert

Robert Haas wrote:
> > This is no harder than many of the other seemingly crazy things I have
> > done, e.g. Win32 port, client library threading. ?If this is a feature
> > we should have, I will get it done or get others to help me complete the
> > task.
>
> Well, I have always thought that it would be sort of a feather in our
> cap to support this, which is why I've done a couple of reviews of it
> in the past. I tend to agree with Tom that only a small fraction of
> our users will probably want it, but then again someone's been paying
> KaiGai to put a pretty hefty amount of work into this over the last
> year-plus, so obviously someone not only wants the feature but wants
> it merged. Within our community, I think that there have been a lot
> of people who have liked the concept of this feature but very few who
> have liked the patch, so there's somewhat of a disconnect between our
> aspirations and our better technical judgment. Tom is a notable
> exception who I believe likes neither the concept nor the patch, which
> is something we may need to resolve before getting too serious about
> this.

Agreed. SE-Linux support might expand our user base and give us
additional credibility, or it might be a feature that few people use ---
and I don't think anyone knows the outcome.

I wonder if we should rephrase this as, "How hard will this feature be
to add, and how hard will it be to remove in a few years if we decide we
don't want it?" SE-Linux support would certainly put Postgres in a
unique security category, and it builds on our existing good security
reputation.

Personally, I think AppArmor is a saner security system:

http://www.novell.com/linux/security/apparmor/selinux_comparison.html
(Novell-hosted URL)

but I am not advocating AppArmor support. I think the whole issue is
whether support for external integrated security systems is appropriate
for Postgres.

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

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

On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> > This is no harder than many of the other seemingly crazy things I have
>> > done, e.g. Win32 port, client library threading. ?If this is a feature
>> > we should have, I will get it done or get others to help me complete the
>> > task.
>>
>> Well, I have always thought that it would be sort of a feather in our
>> cap to support this, which is why I've done a couple of reviews of it
>> in the past.  I tend to agree with Tom that only a small fraction of
>> our users will probably want it, but then again someone's been paying
>> KaiGai to put a pretty hefty amount of work into this over the last
>> year-plus, so obviously someone not only wants the feature but wants
>> it merged.  Within our community, I think that there have been a lot
>> of people who have liked the concept of this feature but very few who
>> have liked the patch, so there's somewhat of a disconnect between our
>> aspirations and our better technical judgment.  Tom is a notable
>> exception who I believe likes neither the concept nor the patch, which
>> is something we may need to resolve before getting too serious about
>> this.
>
> Agreed.  SE-Linux support might expand our user base and give us
> additional credibility, or it might be a feature that few people use ---
> and I don't think anyone knows the outcome.
>
> I wonder if we should rephrase this as, "How hard will this feature be
> to add, and how hard will it be to remove in a few years if we decide we
> don't want it?"  SE-Linux support would certainly put Postgres in a
> unique security category, and it builds on our existing good security
> reputation.

Yes, I think that's the right way to think about it. At a guess, it's
two man-months of work to get it in, and ripping it out is likely
technically fairly simple but will probably be politically impossible.

> Personally, I think AppArmor is a saner security system:
>
>        http://www.novell.com/linux/security/apparmor/selinux_comparison.html
>        (Novell-hosted URL)

Agreed.

> but I am not advocating AppArmor support.  I think the whole issue is
> whether support for external integrated security systems is appropriate
> for Postgres.

It's not something I've run into a need for in my own work, but I
think there are definitely people out there who do need it, and I'd
like to see us be able to support it. One of the things that I think
would be worth looking into is whether there is a way to make this
pluggable, so that selinux and apparmor and trusted solaris and so on
could make use of the same framework, but that requires understanding
all of them well enough to design a framework that can meet all of
those needs. Every framework effort we've seen from KaiGai so far has
seemed extremely SE-Linux-specific and therefore pointless. But
really doing this right is a big development project, and not
something I can do in my free time.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:

>> Personally, I think AppArmor is a saner security system:
>>
>>
http://www.novell.com/linux/security/apparmor/selinux_comparison.html

> Agreed.

> I'd like to see us be able to support it. One of the things that
> I think would be worth looking into is whether there is a way to
> make this pluggable, so that selinux and apparmor and trusted
> solaris and so on could make use of the same framework

Given the extreme patience and diligence exhibited by KaiGai, I
hesitate to say this, but it seems to me that this would be
critically important for the long term success of this feature. I
have no idea how much work it would be to make the interface to the
external security system pluggable, but if it's at all feasible, I
think it should be done.

-Kevin

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> I wonder if we should rephrase this as, "How hard will this feature be
>> to add, and how hard will it be to remove in a few years if we decide we
>> don't want it?"

> Yes, I think that's the right way to think about it. At a guess, it's
> two man-months of work to get it in,

It's not the "get it in" part that scares me. The problem I have with
it is that I see it as a huge time sink for future maintenance problems,
most of which will be classifiable as security breaches which increases
the pain of dealing with them immeasurably.

If I had more confidence that the basic design was right or useful
I might not be so worried about the maintenance prospects, but frankly
I have almost no confidence in it. This comes back to the lack of
involvement of any potential user community.

regards, tom lane

Kevin Grittner escribió:

> > I'd like to see us be able to support it. One of the things that
> > I think would be worth looking into is whether there is a way to
> > make this pluggable, so that selinux and apparmor and trusted
> > solaris and so on could make use of the same framework
>
> Given the extreme patience and diligence exhibited by KaiGai, I
> hesitate to say this, but it seems to me that this would be
> critically important for the long term success of this feature. I
> have no idea how much work it would be to make the interface to the
> external security system pluggable, but if it's at all feasible, I
> think it should be done.

This is how the code was developed initially -- the patch was called
PGACE and SELinux was but the first implementation on top of it.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote:
> > Given the extreme patience and diligence exhibited by KaiGai, I
> > hesitate to say this, but it seems to me that this would be
> > critically important for the long term success of this feature. I
> > have no idea how much work it would be to make the interface to the
> > external security system pluggable, but if it's at all feasible, I
> > think it should be done.
>
> This is how the code was developed initially -- the patch was called
> PGACE and SELinux was but the first implementation on top of it.

I find it astonishing that after SE-PgSQL was implemented on top of a
pluggable system (PGACE) and this system was removed at request of the
"community" [1] that at this late phase people are suggesting it needs
to be added back again. Havn't the goalposts been moved enough times?

[1] http://archives.postgresql.org/pgsql-hackers/2009-01/msg02295.php

(It seems we've gone from a patch that had been around for years
solving actual people's problems to a patch which does barely anything
and we don't know whether it solves anybodies problem).

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> I wonder if we should rephrase this as, "How hard will this feature be
>>> to add, and how hard will it be to remove in a few years if we decide we
>>> don't want it?"
>
>> Yes, I think that's the right way to think about it. At a guess, it's
>> two man-months of work to get it in,
>
> It's not the "get it in" part that scares me. The problem I have with
> it is that I see it as a huge time sink for future maintenance problems,
> most of which will be classifiable as security breaches which increases
> the pain of dealing with them immeasurably.

Ah, yes, the importance of this is not to be underestimated...

Once "SE-Pg" is added in, *any* bug found in it is likely to be
considered a security bug, and hence a candidate for being a CERT
Advisory.

Some bad things are liable to happen:

a) Such problems turn into a "hue and cry" situation requiring
dropping everything else to "fix the security problem."

b) If everyone isn't using "SE-Pg", then people won't be particularly
looking for bugs, and hence bugs are likely to linger somewhat,
with the consequence that a) occurs with some frequency.

c) Having a series of CERT advisories issued is not going to be
considered a good thing, reputation-wise!

I feel about the same way about this as I did about the adding of
"native Windows" support; I'm a bit concerned that this could be a
destabilizing influence. I was wrong back then; the Windows support
hasn't had the ill effects I was concerned it might have.

I'd hope that my concerns about "SE-Pg" are just as wrong as my concerns
about native Windows support. Hope doesn't make it so, alas...
--
select 'cbbrowne' || '@' || 'gmail.com';
http://www3.sympatico.ca/cbbrowne/languages.html
"Just because it's free doesn't mean you can afford it." -- Unknown

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> I find it astonishing that after SE-PgSQL was implemented on top of a
> pluggable system (PGACE) and this system was removed at request of the
> "community" [1] that at this late phase people are suggesting it needs
> to be added back again. Havn't the goalposts been moved enough times?

The reason the goalposts keep moving is that nobody has a very clear
handle on what the requirements are, which stems from the lack of a
clear target community with definable needs. We have had a couple of
apparently-knowledgeable people pop up and say "you should do this",
but then they disappear again without sticking around for any detailed
discussion of features (let alone code).

> (It seems we've gone from a patch that had been around for years
> solving actual people's problems to a patch which does barely anything
> and we don't know whether it solves anybodies problem).

Do we know that any version of this patch has solved any actual people's
problems? I know KaiGai-san has been putting it out as a Fedora package
but there's little if any evidence that anyone's actually using that.

regards, tom lane

Chris Browne <cbbrowne(at)acm(dot)org> writes:
> I feel about the same way about this as I did about the adding of
> "native Windows" support; I'm a bit concerned that this could be a
> destabilizing influence. I was wrong back then; the Windows support
> hasn't had the ill effects I was concerned it might have.

That's an interesting analogy. I too am not entirely convinced that
it's a good comparison, but if it is, consider these points:

* The goal of the Windows port was pretty well-defined and easily
tested: "make it work on Windows". The goalposts didn't move except
perhaps when MS came out with new Windows versions.

* We had a *lot* of users available to help flush out problems.

* There wasn't any need to treat bugs as security sensitive, which is
problematic not least because it restricts the free flow of information.

Any one of those points would be good reason to think that getting
SEPostgres to stability will be lots more drawn-out and painful than
getting the Windows port to stability was. With all three pointing in
the same direction, the tea leaves don't look good.

regards, tom lane

Robert Haas wrote:
> > Agreed. ?SE-Linux support might expand our user base and give us
> > additional credibility, or it might be a feature that few people use ---
> > and I don't think anyone knows the outcome.
> >
> > I wonder if we should rephrase this as, "How hard will this feature be
> > to add, and how hard will it be to remove in a few years if we decide we
> > don't want it?" ?SE-Linux support would certainly put Postgres in a
> > unique security category, and it builds on our existing good security
> > reputation.
>
> Yes, I think that's the right way to think about it. At a guess, it's
> two man-months of work to get it in, and ripping it out is likely
> technically fairly simple but will probably be politically impossible.

I figure if there is sufficient usage, we will not need to remove it,
and if there isn't, we will have no objections to removing it.

> > but I am not advocating AppArmor support. ?I think the whole issue is
> > whether support for external integrated security systems is appropriate
> > for Postgres.
>
> It's not something I've run into a need for in my own work, but I
> think there are definitely people out there who do need it, and I'd
> like to see us be able to support it. One of the things that I think
> would be worth looking into is whether there is a way to make this
> pluggable, so that selinux and apparmor and trusted solaris and so on
> could make use of the same framework, but that requires understanding
> all of them well enough to design a framework that can meet all of
> those needs. Every framework effort we've seen from KaiGai so far has
> seemed extremely SE-Linux-specific and therefore pointless. But
> really doing this right is a big development project, and not
> something I can do in my free time.

As Alvaro mentioned, the original patch used ACE but it added too much
code so the community requested its removal from the patch. It could be
re-added if we have a need.

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

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

Martijn van Oosterhout escribió:
> On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote:

> > This is how the code was developed initially -- the patch was called
> > PGACE and SELinux was but the first implementation on top of it.
>
> I find it astonishing that after SE-PgSQL was implemented on top of a
> pluggable system (PGACE) and this system was removed at request of the
> "community" [1] that at this late phase people are suggesting it needs
> to be added back again. Havn't the goalposts been moved enough times?

Yeah. I think the idle discussions here have created more work
themselves than the hypothetical maintenance work that would be spent on
this (undoubtely useful) feature.

> (It seems we've gone from a patch that had been around for years
> solving actual people's problems to a patch which does barely anything
> and we don't know whether it solves anybodies problem).

Agreed :-(

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Robert Haas wrote:
>> Yes, I think that's the right way to think about it. At a guess, it's
>> two man-months of work to get it in, and ripping it out is likely
>> technically fairly simple but will probably be politically impossible.

> I figure if there is sufficient usage, we will not need to remove it,
> and if there isn't, we will have no objections to removing it.

That leaves a wide gray area where there are a few people using it but
not really enough to justify the support effort. Even if there are
demonstrably no users (which can never be demonstrated in practice),
politically it's very hard to rip out a "major feature" --- it makes the
project look bad. So I think the above is Pollyanna-ish nonsense.
Once we ship a release with SEPostgres in it, we're committed.

> As Alvaro mentioned, the original patch used ACE but it added too much
> code so the community requested its removal from the patch. It could be
> re-added if we have a need.

The main problem I saw with ACE was that it didn't appear to actually
add any flexibility --- it was just an extra layer of function calls
in an entirely SELinux-centric design. In order to have a "pluggable
interface" layer that is worth the electrons it's written on, you need
to start out with more than one target system in mind to be plugged in.
So that would mean, at minimum, investigating something like AppArmor or
TrustedSolaris to see what its needs are before we sit down to design
the plugin layer. (Which, of course, nobody here is actually interested
enough to do. But without that research there is no point in demanding
a plugin layer.)

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Robert Haas wrote:
> >> Yes, I think that's the right way to think about it. At a guess, it's
> >> two man-months of work to get it in, and ripping it out is likely
> >> technically fairly simple but will probably be politically impossible.
>
> > I figure if there is sufficient usage, we will not need to remove it,
> > and if there isn't, we will have no objections to removing it.
>
> That leaves a wide gray area where there are a few people using it but
> not really enough to justify the support effort. Even if there are
> demonstrably no users (which can never be demonstrated in practice),
> politically it's very hard to rip out a "major feature" --- it makes the
> project look bad. So I think the above is Pollyanna-ish nonsense.

I don't even know what "Pollyanna-ish nonsense" means, and it would be
better if you used less flowery/inflamitory prose.

> Once we ship a release with SEPostgres in it, we're committed.

The MS Windows port took 1-2 years to solidify and during the
solidification period we accepted problems and didn't treat it as a
major platform. I think if SE-Linux support is added, there would be a
similar period where the features is not treated as major while we work
out any problems. We might even label it that way.

Labeling SE-Postgres as such might minimize the political problems of
removing it in the future, if that becomes necessary.

I know there has been complaints about the lack of SE-PostgreSQL
developers, but given the number of developers we had for the Win32 port
vs. the installed base, I think having one dedicated SE-PostgreSQL
developer is much more percentage-wise than we had for MS Windows.

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

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

On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> As Alvaro mentioned, the original patch used ACE but it added too much
> code so the community requested its removal from the patch.  It could be
> re-added if we have a need.

Well, there's no point in putting that framework back in unless we can
make it sufficiently general that it could be used to serve the needs
of more than one security model. And so far, the signs have not been
promising. David Quigley suggests downthread that making a truly
general model isn't really possible, and he may be right, or not. I
was just mentioning that it's an angle I have been thinking about
investigating, but it may be a dead end.

The real issue is making the code committable, and then maintaining
it, as Tom rightly says, forever. We've got to make sure that we're
willing to take that on before we do it, and I don't think it's a
small task. It isn't so much whether we want the feature as whether
the level of effort is proportionate to the benefit.

...Robert

Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Dec 7, 2009 at 9:48 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> I wonder if we should rephrase this as, "How hard will this feature be
>>> to add, and how hard will it be to remove in a few years if we decide we
>>> don't want it?"
>
>> Yes, I think that's the right way to think about it. At a guess, it's
>> two man-months of work to get it in,
>
> It's not the "get it in" part that scares me. The problem I have with
> it is that I see it as a huge time sink for future maintenance problems,
> most of which will be classifiable as security breaches which increases
> the pain of dealing with them immeasurably.

We can clearly say that acception of this feature is equivalent to
getting a new developer to maintain this feature into the community.

It is preferable to change my role in this community; I'd like to perform
as a maintainer of this feature rather than a person who send a large
patch for each commit-fest.

> If I had more confidence that the basic design was right or useful
> I might not be so worried about the maintenance prospects, but frankly
> I have almost no confidence in it. This comes back to the lack of
> involvement of any potential user community.

We should not ignore a fact several commercial database software provides
advanced security options that are partially similar to SE-PgSQL. It allows
them to reach a region where PgSQL has not reached yet, and these features
are supported by an amount of users.

Anyway, it seems to me it is counterproductive to discuss whether the
potential users are larger or smaller, because it is a difficult job
to estimate it correctly, even if we would be experienced marketers.

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

Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> Robert Haas wrote:
>>>> Yes, I think that's the right way to think about it. At a guess, it's
>>>> two man-months of work to get it in, and ripping it out is likely
>>>> technically fairly simple but will probably be politically impossible.
>>> I figure if there is sufficient usage, we will not need to remove it,
>>> and if there isn't, we will have no objections to removing it.
>> That leaves a wide gray area where there are a few people using it but
>> not really enough to justify the support effort. Even if there are
>> demonstrably no users (which can never be demonstrated in practice),
>> politically it's very hard to rip out a "major feature" --- it makes the
>> project look bad. So I think the above is Pollyanna-ish nonsense.
>
> I don't even know what "Pollyanna-ish nonsense" means, and it would be
> better if you used less flowery/inflamitory prose.

Apart from standpoint of the discussion, idiomatic phrases are not
oftern friendly for non-native English speakers.

>> Once we ship a release with SEPostgres in it, we're committed.
>
> The MS Windows port took 1-2 years to solidify and during the
> solidification period we accepted problems and didn't treat it as a
> major platform. I think if SE-Linux support is added, there would be a
> similar period where the features is not treated as major while we work
> out any problems. We might even label it that way.

It also seems to me an realistic attitude.
The first guy needs courage independently from the class of features.
Thus, anybody attend to see case examples in conferences. I don't think
here is no fundamental differences.

> Labeling SE-Postgres as such might minimize the political problems of
> removing it in the future, if that becomes necessary.

For us, the name is not an important issue.
And, I believe our continued contributions in the future shall make it
unnecessary to remove it later.

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

Robert Haas wrote:
> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> As Alvaro mentioned, the original patch used ACE but it added too much
>> code so the community requested its removal from the patch. It could be
>> re-added if we have a need.
>
> Well, there's no point in putting that framework back in unless we can
> make it sufficiently general that it could be used to serve the needs
> of more than one security model. And so far, the signs have not been
> promising. David Quigley suggests downthread that making a truly
> general model isn't really possible, and he may be right, or not. I
> was just mentioning that it's an angle I have been thinking about
> investigating, but it may be a dead end.

I also agree that the common framework just increases complexity of
the patch at the moment.

> The real issue is making the code committable, and then maintaining
> it, as Tom rightly says, forever. We've got to make sure that we're
> willing to take that on before we do it, and I don't think it's a
> small task. It isn't so much whether we want the feature as whether
> the level of effort is proportionate to the benefit.

Needless to say, we can provide development resource to maintain this
feature. If we escape to anywhere just after commit it, it will be removed
as Bruce pointed out. But it shall be incorrect.

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

I could not find the message from David P. Quigley in the list,
although pgsql-hackers(at)postgresql(dot)org was Cc:'ed.
(something troubled?)

So, I'll send it again for your information.

-------- Original Message --------
Subject: Re: [HACKERS] Adding support for SE-Linux security
Date: Mon, 07 Dec 2009 14:53:03 -0500
From: David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov>
Organization: National Security Agency
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
CC: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, jd(at)commandprompt(dot)com, David Fetter <david(at)fetter(dot)org>, Itagaki Takahiro
<itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org
References: <200912071800(dot)nB7I0KB01863(at)momjian(dot)us> <21873(dot)1260209825(at)sss(dot)pgh(dot)pa(dot)us>

On Mon, 2009-12-07 at 13:17 -0500, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Robert Haas wrote:
> >> Yes, I think that's the right way to think about it. At a guess, it's
> >> two man-months of work to get it in, and ripping it out is likely
> >> technically fairly simple but will probably be politically impossible.
>
> > I figure if there is sufficient usage, we will not need to remove it,
> > and if there isn't, we will have no objections to removing it.
>
> That leaves a wide gray area where there are a few people using it but
> not really enough to justify the support effort. Even if there are
> demonstrably no users (which can never be demonstrated in practice),
> politically it's very hard to rip out a "major feature" --- it makes the
> project look bad. So I think the above is Pollyanna-ish nonsense.
> Once we ship a release with SEPostgres in it, we're committed.
>
> > As Alvaro mentioned, the original patch used ACE but it added too much
> > code so the community requested its removal from the patch. It could be
> > re-added if we have a need.
>
> The main problem I saw with ACE was that it didn't appear to actually
> add any flexibility --- it was just an extra layer of function calls
> in an entirely SELinux-centric design. In order to have a "pluggable
> interface" layer that is worth the electrons it's written on, you need
> to start out with more than one target system in mind to be plugged in.
> So that would mean, at minimum, investigating something like AppArmor or
> TrustedSolaris to see what its needs are before we sit down to design
> the plugin layer. (Which, of course, nobody here is actually interested
> enough to do. But without that research there is no point in demanding
> a plugin layer.)
>
> regards, tom lane
>

Not to start a flame war here about access control models but you gave 3
different examples one of which I don't think has any means to do
anything productive here. Looking at the 3 examples you gave and what
SEPostgres is trying to accomplish here is what I see.

The point of SEPostgres is to do object labeling in a database. Two of
the three examples you gave are label based security mechanisms.
AppArmor while it might be able to have a scheme to mediate access to
database/table doesn't seem to have a reasonable way to write policy to
individual records. Since AppArmor is path name based you need an
identifiable path to whatever you want to write access control rules
for. With something like a database where data dynamically comes and
goes and changes doing rules on individual records seems difficult. I
also can't find any information about AppArmor being used as a
user-space object manager. If someone wants to prove me wrong I'm
willing to listen to their argument.

Lets look at the remaining two. Do you really mean TrustedSolaris(TSOL)
or do you mean Solaris with Trusted Extensions(TX). There is a big
difference here. From my understanding Sun no longer supports TSOL and
moved on to TX. The difference here is that they moved from fine grained
object labeling to zone based labeling. There is a project currently in
development (although moving a bit slow) called FMAC which will bring
SELinux style MAC to Solaris which will reintroduce fine grained
labeling. You will still be able to use zones however process and object
labels will not be based on zone in FMAC.

I understand the concerns with a generic framework introducing a lot of
code. The Linux Kernel LSM Framework seems to grow as more models are
introduced but if you want to support various models you have to live
with the fact that there is no common interface for all of these
systems. It has been tried numerous times in the past and has failed.
>From what I've seen I think that will be less of a concern with Postgres
since the objects that Kaigai wants to mediate is a much smaller set
than the kernel. If you want to see another instance of where work
similar to this was done you should look at the X-Access Control
eXtensions (X-ACE) found in the X server. Eamon Walsh designed this
framework based not on anything SELinux specific but through an analysis
of the X Server which yielded a list of object he though needed
mediating. There are two modules for X-ACE now the FLASK module
(SELinux) and a module put forth by Casey Schaufler for his SMACK work.
>From what I've seen on the SELinux list Kaigai's design of SEPostgres
was conducted in a similar way.

I'll be willing to answer any questions you have for me in order to help
Kaigai's work along. Normally another member of our team would be
participating in this but he is unavailable at the moment. When he is
available again I'm sure he will participate in the discussion.

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

KaiGai Kohei escribió:
> I could not find the message from David P. Quigley in the list,
> although pgsql-hackers(at)postgresql(dot)org was Cc:'ed.
> (something troubled?)

Weird. It didn't even made it to the moderator queue for some reason.
Perhaps the system dropped it as spam.

> So, I'll send it again for your information.

Good move.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

David P. Quigley wrote:
> Not to start a flame war here about access control models but you gave 3
> different examples one of which I don't think has any means to do
> anything productive here.
You won't be starting a flame war for the same reason some of the
community members are so concerned about this patch. There aren't enough
people familiar with this part of the security field within our database
developer community to even be able to answer fairly basic questions
like the one you just clarified. If you can help bring more qualified
reviewers to bear on that, it would be extremely helpful. I even tried
to organize a meetup between PostgreSQL hackers working in this area and
the security people I knew around here (Baltimore/DC) last year, but
just couldn't find any interested enough to show. Other than a brief
visit on this list from some of the Tresys guys, we haven't seen much
input here beyond that offered by the patch author, who's obviously
qualified but at the end of the day is still only one opinion. He's also
not in a good position to tell other people their ideas are misinformed
either.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

On Mon, 2009-12-07 at 22:25 -0500, Greg Smith wrote:
> David P. Quigley wrote:
> > Not to start a flame war here about access control models but you gave 3
> > different examples one of which I don't think has any means to do
> > anything productive here.
> You won't be starting a flame war for the same reason some of the
> community members are so concerned about this patch. There aren't enough
> people familiar with this part of the security field within our database
> developer community to even be able to answer fairly basic questions
> like the one you just clarified. If you can help bring more qualified
> reviewers to bear on that, it would be extremely helpful. I even tried
> to organize a meetup between PostgreSQL hackers working in this area and
> the security people I knew around here (Baltimore/DC) last year, but
> just couldn't find any interested enough to show. Other than a brief
> visit on this list from some of the Tresys guys, we haven't seen much
> input here beyond that offered by the patch author, who's obviously
> qualified but at the end of the day is still only one opinion. He's also
> not in a good position to tell other people their ideas are misinformed
> either.
>

I can't make any guarantees on who I can drag to a meeting but if you
wanted to try to organize another meeting between the Postgres people
and some of us I can try to organize it on our end. One of my coworkers
that does a lot of commenting on stuff like this is on leave at the
moment but when he gets back I'll discuss it with him. I'll also talk
with some of the other people in the area on our end to see what I can
arrange.

If you have any questions in the meantime feel free to ask. If there are
any specific parts of the patch that you'd like discussed I can do that
as well. I do have to agree though that I'd rather see KaiGai's original
security plugin framework go in and then merge a particular security
module after that.From what I see it would require at least the hook
framework and the label storage mechanism. I feel bad saying that
knowing the KaiGai spent a lot of time ripping all of that out. However
if you are concerned about supporting more than just SELinux as a MAC
model then the plugin framework he originally proposed is the better
solution.

I'd be willing to take a look at the framework and see if it really is
SELinux centric. If it is we can figure out if there is a way to
accomodate something like SMACK and FMAC. I'd like to hear from someone
with more extensive experience with Solaris Trusted Extensions about how
TX would make use of this. I have a feeling it would be similar to the
way it deals with NFS which is by having the process exist in the global
zone as a privileged process and then multi-plexes it to the remaining
zones. That way their getpeercon would get a label derived from the
zone.

Dave

On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
> I'd be willing to take a look at the framework and see if it really is
> SELinux centric. If it is we can figure out if there is a way to
> accomodate something like SMACK and FMAC. I'd like to hear from someone
> with more extensive experience with Solaris Trusted Extensions about how
> TX would make use of this. I have a feeling it would be similar to the
> way it deals with NFS which is by having the process exist in the global
> zone as a privileged process and then multi-plexes it to the remaining
> zones. That way their getpeercon would get a label derived from the
> zone.

Well, the old patches should still be available in the mailing list
archives. Maybe going back and looking at that code would be a good
place to start. The non-ripped-out code has been cleaned up a lot
since then, but at least it's a place to start.

...Robert

On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> > As Alvaro mentioned, the original patch used ACE but it added too much
>> > code so the community requested its removal from the patch.  It could be
>> > re-added if we have a need.
>>
>> Well, there's no point in putting that framework back in unless we can
>> make it sufficiently general that it could be used to serve the needs
>> of more than one security model.  And so far, the signs have not been
>> promising.  David Quigley suggests downthread that making a truly
>> general model isn't really possible, and he may be right, or not.  I
>> was just mentioning that it's an angle I have been thinking about
>> investigating, but it may be a dead end.
>>
>> The real issue is making the code committable, and then maintaining
>> it, as Tom rightly says, forever.  We've got to make sure that we're
>> willing to take that on before we do it, and I don't think it's a
>> small task.  It isn't so much whether we want the feature as whether
>> the level of effort is proportionate to the benefit.
>>
>> ...Robert
>>
>
> So the issue with generality is that path name based MAC has a different
> set of requirements than label based does. If you want to acomodate
> several types of label based MAC models then a framework can be
> developed for that similar to the one in the Linux Kernel. I asked
> around after I sent the email yesterday and from what I understand
> AppArmor does not have the concept of a userspace object manager so I
> don't know what they'd do in this area. I'm sure they could come up with
> a scheme to write policy for the database but I don't know how useful it
> would be.
>
> If you look at the LSM framework in the Linux Kernel recently there have
> been hooks added to accomodate path based MAC systems so it can be done
> but adds another set of hooks. The important goal here though in
> designing a framework is to make sure that you have a comprehensive list
> of the objects you want to mediate and make sure you put the proper
> enforcement points in. Someone may come along later and want to mediate
> a new object or some new functionality may come along that introduces a
> new object so a hook may then need to be added. Something to realize as
> well is that a security model may not want to implement all of the hooks
> and it doesn't have to. In the case of no module being loaded or someone
> not wanting the loadable security module framework I'm sure we can
> provide an option to reduce overhead or compile the framework out
> completely.
>
> I'll take a look at his patches for the framework that KaiGai originally
> proposed.

It sounds like the pathname-based schemes are not really designed to
work inside of a database anyway, so my first thought is we shouldn't
worry about them. The label-based schemes are by their nature
designed to apply in an arbitrary context being applied to arbitrary
objects.

...Robert

On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
> > On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
> >> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> > As Alvaro mentioned, the original patch used ACE but it added too much
> >> > code so the community requested its removal from the patch. It could be
> >> > re-added if we have a need.
> >>
> >> Well, there's no point in putting that framework back in unless we can
> >> make it sufficiently general that it could be used to serve the needs
> >> of more than one security model. And so far, the signs have not been
> >> promising. David Quigley suggests downthread that making a truly
> >> general model isn't really possible, and he may be right, or not. I
> >> was just mentioning that it's an angle I have been thinking about
> >> investigating, but it may be a dead end.
> >>
> >> The real issue is making the code committable, and then maintaining
> >> it, as Tom rightly says, forever. We've got to make sure that we're
> >> willing to take that on before we do it, and I don't think it's a
> >> small task. It isn't so much whether we want the feature as whether
> >> the level of effort is proportionate to the benefit.
> >>
> >> ...Robert
> >>
> >
> > So the issue with generality is that path name based MAC has a different
> > set of requirements than label based does. If you want to acomodate
> > several types of label based MAC models then a framework can be
> > developed for that similar to the one in the Linux Kernel. I asked
> > around after I sent the email yesterday and from what I understand
> > AppArmor does not have the concept of a userspace object manager so I
> > don't know what they'd do in this area. I'm sure they could come up with
> > a scheme to write policy for the database but I don't know how useful it
> > would be.
> >
> > If you look at the LSM framework in the Linux Kernel recently there have
> > been hooks added to accomodate path based MAC systems so it can be done
> > but adds another set of hooks. The important goal here though in
> > designing a framework is to make sure that you have a comprehensive list
> > of the objects you want to mediate and make sure you put the proper
> > enforcement points in. Someone may come along later and want to mediate
> > a new object or some new functionality may come along that introduces a
> > new object so a hook may then need to be added. Something to realize as
> > well is that a security model may not want to implement all of the hooks
> > and it doesn't have to. In the case of no module being loaded or someone
> > not wanting the loadable security module framework I'm sure we can
> > provide an option to reduce overhead or compile the framework out
> > completely.
> >
> > I'll take a look at his patches for the framework that KaiGai originally
> > proposed.
>
> It sounds like the pathname-based schemes are not really designed to
> work inside of a database anyway, so my first thought is we shouldn't
> worry about them. The label-based schemes are by their nature
> designed to apply in an arbitrary context being applied to arbitrary
> objects.
>
> ...Robert

So I was reading through a set of slides that KaiGai has and he
mentioned a May commitfest link and I looked for the comments related to
his PGACE patches. I've been crawling through the commitfest paces so I
can figure out what the latest version of the pgace patch is. Does
anyone know when the patch was reduced to what it is today?

Dave

On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:

> On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
>> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov>
>> wrote:
>>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
>>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>>>> As Alvaro mentioned, the original patch used ACE but it added too much
>>>>> code so the community requested its removal from the patch. It could be
>>>>> re-added if we have a need.
>>>>
>>>> Well, there's no point in putting that framework back in unless we can
>>>> make it sufficiently general that it could be used to serve the needs
>>>> of more than one security model. And so far, the signs have not been
>>>> promising. David Quigley suggests downthread that making a truly
>>>> general model isn't really possible, and he may be right, or not. I
>>>> was just mentioning that it's an angle I have been thinking about
>>>> investigating, but it may be a dead end.
>>>>
>>>> The real issue is making the code committable, and then maintaining
>>>> it, as Tom rightly says, forever. We've got to make sure that we're
>>>> willing to take that on before we do it, and I don't think it's a
>>>> small task. It isn't so much whether we want the feature as whether
>>>> the level of effort is proportionate to the benefit.
>>>>
>>>> ...Robert
>>>>
>>>
>>> So the issue with generality is that path name based MAC has a different
>>> set of requirements than label based does. If you want to acomodate
>>> several types of label based MAC models then a framework can be
>>> developed for that similar to the one in the Linux Kernel. I asked
>>> around after I sent the email yesterday and from what I understand
>>> AppArmor does not have the concept of a userspace object manager so I
>>> don't know what they'd do in this area. I'm sure they could come up with
>>> a scheme to write policy for the database but I don't know how useful it
>>> would be.
>>>
>>> If you look at the LSM framework in the Linux Kernel recently there have
>>> been hooks added to accomodate path based MAC systems so it can be done
>>> but adds another set of hooks. The important goal here though in
>>> designing a framework is to make sure that you have a comprehensive list
>>> of the objects you want to mediate and make sure you put the proper
>>> enforcement points in. Someone may come along later and want to mediate
>>> a new object or some new functionality may come along that introduces a
>>> new object so a hook may then need to be added. Something to realize as
>>> well is that a security model may not want to implement all of the hooks
>>> and it doesn't have to. In the case of no module being loaded or someone
>>> not wanting the loadable security module framework I'm sure we can
>>> provide an option to reduce overhead or compile the framework out
>>> completely.
>>>
>>> I'll take a look at his patches for the framework that KaiGai originally
>>> proposed.
>>
>> It sounds like the pathname-based schemes are not really designed to
>> work inside of a database anyway, so my first thought is we shouldn't
>> worry about them. The label-based schemes are by their nature
>> designed to apply in an arbitrary context being applied to arbitrary
>> objects.
>>
>> ...Robert
>
>
> So I was reading through a set of slides that KaiGai has and he
> mentioned a May commitfest link and I looked for the comments related to
> his PGACE patches. I've been crawling through the commitfest paces so I
> can figure out what the latest version of the pgace patch is. Does
> anyone know when the patch was reduced to what it is today?
>
> Dave
>
I'm another SELinux developer and I'd like to help out where I can here. I'm
a bit confused by this discussion of PGACE. I thought the postgresql
community agreed that they wanted this removed in order to make the patch
size smaller. Has that changed? Is the increase in patch size now
acceptable? Sorry if I'm joining the conversation late.

Thanks,
Chad Sellers

On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers <csellers(at)tresys(dot)com> wrote:
> On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
>
>> On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
>>> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov>
>>> wrote:
>>>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
>>>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>>>>> As Alvaro mentioned, the original patch used ACE but it added too much
>>>>>> code so the community requested its removal from the patch.  It could be
>>>>>> re-added if we have a need.
>>>>>
>>>>> Well, there's no point in putting that framework back in unless we can
>>>>> make it sufficiently general that it could be used to serve the needs
>>>>> of more than one security model.  And so far, the signs have not been
>>>>> promising.  David Quigley suggests downthread that making a truly
>>>>> general model isn't really possible, and he may be right, or not.  I
>>>>> was just mentioning that it's an angle I have been thinking about
>>>>> investigating, but it may be a dead end.
>>>>>
>>>>> The real issue is making the code committable, and then maintaining
>>>>> it, as Tom rightly says, forever.  We've got to make sure that we're
>>>>> willing to take that on before we do it, and I don't think it's a
>>>>> small task.  It isn't so much whether we want the feature as whether
>>>>> the level of effort is proportionate to the benefit.
>>>>>
>>>>> ...Robert
>>>>>
>>>>
>>>> So the issue with generality is that path name based MAC has a different
>>>> set of requirements than label based does. If you want to acomodate
>>>> several types of label based MAC models then a framework can be
>>>> developed for that similar to the one in the Linux Kernel. I asked
>>>> around after I sent the email yesterday and from what I understand
>>>> AppArmor does not have the concept of a userspace object manager so I
>>>> don't know what they'd do in this area. I'm sure they could come up with
>>>> a scheme to write policy for the database but I don't know how useful it
>>>> would be.
>>>>
>>>> If you look at the LSM framework in the Linux Kernel recently there have
>>>> been hooks added to accomodate path based MAC systems so it can be done
>>>> but adds another set of hooks. The important goal here though in
>>>> designing a framework is to make sure that you have a comprehensive list
>>>> of the objects you want to mediate and make sure you put the proper
>>>> enforcement points in. Someone may come along later and want to mediate
>>>> a new object or some new functionality may come along that introduces a
>>>> new object so a hook may then need to be added. Something to realize as
>>>> well is that a security model may not want to implement all of the hooks
>>>> and it doesn't have to. In the case of no module being loaded or someone
>>>> not wanting the loadable security module framework I'm sure we can
>>>> provide an option to reduce overhead or compile the framework out
>>>> completely.
>>>>
>>>> I'll take a look at his patches for the framework that KaiGai originally
>>>> proposed.
>>>
>>> It sounds like the pathname-based schemes are not really designed to
>>> work inside of a database anyway, so my first thought is we shouldn't
>>> worry about them.  The label-based schemes are by their nature
>>> designed to apply in an arbitrary context being applied to arbitrary
>>> objects.
>>>
>>> ...Robert
>>
>>
>> So I was reading through a set of slides that KaiGai has and he
>> mentioned a May commitfest link and I looked for the comments related to
>> his PGACE patches. I've been crawling through the commitfest paces so I
>> can figure out what the latest version of the pgace patch is. Does
>> anyone know when the patch was reduced to what it is today?
>>
>> Dave
>>
> I'm another SELinux developer and I'd like to help out where I can here. I'm
> a bit confused by this discussion of PGACE. I thought the postgresql
> community agreed that they wanted this removed in order to make the patch
> size smaller. Has that changed? Is the increase in patch size now
> acceptable? Sorry if I'm joining the conversation late.
>
> Thanks,
> Chad Sellers

Nothing's been decided. We're just trying to figure out the best way
to tackle the problem. I think the main question here is who if
anyone from among the committers is willing to put in the time and
effort to maintain this feature over the short and long haul, but
that's sort of an internal project issue. I was just thinking out
loud about whether it was possible and/or desirable to try to
modularize this a bit so that it could be used for more than just
SE-Linux. Obviously, the labeling stuff could be generalize to
accomodate a label from an arbitrary security system, but that's only
a small piece of the problem.

One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the code. It would be nice
if it were possible to use the exist permissions-checking functions
and have them check a few more things while they're at it, but it's
looking like that won't be feasible, or at least no one's come up with
a plausible design yet. Consequently there are checks spread
throughout the code, which definitely complicates both validation and
maintenance. One question I have is - are the places where those
checks are placed specific to SE-Linux, or would they be applicable to
any sort of label-based MAC?

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> One of the major and fundamental stumbling blocks we've run into is
> that every solution we've looked at so far seems to involve adding
> SE-Linux-specific checks in many places in the code. It would be nice
> if it were possible to use the exist permissions-checking functions
> and have them check a few more things while they're at it, but it's
> looking like that won't be feasible, or at least no one's come up with
> a plausible design yet.

I don't think that it's about SELinux. The real issue here is that
KaiGai-san is about a mile out in front of the PG hackers community
in terms of his ambitions for the scope of what can be controlled by
security policy. If the patch were only doing what the community has
actually agreed to, there would be little need for it to touch anything
but the aclcheck functions.

Now I recognize that a large part of the potential attraction in this
for the security community is exactly the idea of having fine-grain
security control. But if you ever want anything significantly different
from SQL-standard permission mechanisms, there's going to have to be a
whole lot more work done. Basically, nobody in the PG community has got
any confidence either in the overall design or the implementation
details for locking things down that aren't already controlled by SQL
permission mechanisms.

regards, tom lane

On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> One of the major and fundamental stumbling blocks we've run into is
>> that every solution we've looked at so far seems to involve adding
>> SE-Linux-specific checks in many places in the code.  It would be nice
>> if it were possible to use the exist permissions-checking functions
>> and have them check a few more things while they're at it, but it's
>> looking like that won't be feasible, or at least no one's come up with
>> a plausible design yet.
>
> I don't think that it's about SELinux.  The real issue here is that
> KaiGai-san is about a mile out in front of the PG hackers community
> in terms of his ambitions for the scope of what can be controlled by
> security policy.  If the patch were only doing what the community has
> actually agreed to, there would be little need for it to touch anything
> but the aclcheck functions.
>
> Now I recognize that a large part of the potential attraction in this
> for the security community is exactly the idea of having fine-grain
> security control.  But if you ever want anything significantly different
> from SQL-standard permission mechanisms, there's going to have to be a
> whole lot more work done.  Basically, nobody in the PG community has got
> any confidence either in the overall design or the implementation
> details for locking things down that aren't already controlled by SQL
> permission mechanisms.

I think that's basically right. Further, I think this is basically a
resource issue. If you were inclined to spend a large amount of your
time on this problem, you could either gain confidence in the present
design and implementation or come up with a new one in which you did
have confidence. But it doesn't seem important enough to you (or your
employer) for the amount of time it would take, so you're not. I
think there are other committers and community members in a similar
situation - basically all of them.

...Robert

On 12/8/09 12:36 PM, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers <csellers(at)tresys(dot)com> wrote:
>> On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
>>
>>> On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
>>>> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov>
>>>> wrote:
>>>>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
>>>>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>>>>>> As Alvaro mentioned, the original patch used ACE but it added too much
>>>>>>> code so the community requested its removal from the patch.  It could be
>>>>>>> re-added if we have a need.
>>>>>>
>>>>>> Well, there's no point in putting that framework back in unless we can
>>>>>> make it sufficiently general that it could be used to serve the needs
>>>>>> of more than one security model.  And so far, the signs have not been
>>>>>> promising.  David Quigley suggests downthread that making a truly
>>>>>> general model isn't really possible, and he may be right, or not.  I
>>>>>> was just mentioning that it's an angle I have been thinking about
>>>>>> investigating, but it may be a dead end.
>>>>>>
>>>>>> The real issue is making the code committable, and then maintaining
>>>>>> it, as Tom rightly says, forever.  We've got to make sure that we're
>>>>>> willing to take that on before we do it, and I don't think it's a
>>>>>> small task.  It isn't so much whether we want the feature as whether
>>>>>> the level of effort is proportionate to the benefit.
>>>>>>
>>>>>> ...Robert
>>>>>>
>>>>>
>>>>> So the issue with generality is that path name based MAC has a different
>>>>> set of requirements than label based does. If you want to acomodate
>>>>> several types of label based MAC models then a framework can be
>>>>> developed for that similar to the one in the Linux Kernel. I asked
>>>>> around after I sent the email yesterday and from what I understand
>>>>> AppArmor does not have the concept of a userspace object manager so I
>>>>> don't know what they'd do in this area. I'm sure they could come up with
>>>>> a scheme to write policy for the database but I don't know how useful it
>>>>> would be.
>>>>>
>>>>> If you look at the LSM framework in the Linux Kernel recently there have
>>>>> been hooks added to accomodate path based MAC systems so it can be done
>>>>> but adds another set of hooks. The important goal here though in
>>>>> designing a framework is to make sure that you have a comprehensive list
>>>>> of the objects you want to mediate and make sure you put the proper
>>>>> enforcement points in. Someone may come along later and want to mediate
>>>>> a new object or some new functionality may come along that introduces a
>>>>> new object so a hook may then need to be added. Something to realize as
>>>>> well is that a security model may not want to implement all of the hooks
>>>>> and it doesn't have to. In the case of no module being loaded or someone
>>>>> not wanting the loadable security module framework I'm sure we can
>>>>> provide an option to reduce overhead or compile the framework out
>>>>> completely.
>>>>>
>>>>> I'll take a look at his patches for the framework that KaiGai originally
>>>>> proposed.
>>>>
>>>> It sounds like the pathname-based schemes are not really designed to
>>>> work inside of a database anyway, so my first thought is we shouldn't
>>>> worry about them.  The label-based schemes are by their nature
>>>> designed to apply in an arbitrary context being applied to arbitrary
>>>> objects.
>>>>
>>>> ...Robert
>>>
>>>
>>> So I was reading through a set of slides that KaiGai has and he
>>> mentioned a May commitfest link and I looked for the comments related to
>>> his PGACE patches. I've been crawling through the commitfest paces so I
>>> can figure out what the latest version of the pgace patch is. Does
>>> anyone know when the patch was reduced to what it is today?
>>>
>>> Dave
>>>
>> I'm another SELinux developer and I'd like to help out where I can here. I'm
>> a bit confused by this discussion of PGACE. I thought the postgresql
>> community agreed that they wanted this removed in order to make the patch
>> size smaller. Has that changed? Is the increase in patch size now
>> acceptable? Sorry if I'm joining the conversation late.
>>
>> Thanks,
>> Chad Sellers
>
> Nothing's been decided.

Sorry, my mistake. This mailing list moves pretty quick so it's hard to
catch up with everything.

> We're just trying to figure out the best way
> to tackle the problem. I think the main question here is who if
> anyone from among the committers is willing to put in the time and
> effort to maintain this feature over the short and long haul, but
> that's sort of an internal project issue. I was just thinking out
> loud about whether it was possible and/or desirable to try to
> modularize this a bit so that it could be used for more than just
> SE-Linux.

So, a generalized framework is nice in that it supports multiple models, but
it does bring with it an additional maintenance burden. I'm sure that's been
discussed at length already.

I will say that it's almost impossible to place hooks properly for imaginary
users. So, if you create a framework, it's probably just a placeholder with
hooks for the one user (SEPostgreSQL) that will later have to be
modified/augmented to support additional users. This is how things went with
LSM. LSM was added to Linux and created with input from several users
(SELinux folks, Immunix (later AppArmor) folks, and others) and still took
years before most of the other mechanisms could use it without extra
patches. If you're trying to build a generalized access control framework
with only one user, it will have to change the day user 2 comes along.

> Obviously, the labeling stuff could be generalize to
> accomodate a label from an arbitrary security system, but that's only
> a small piece of the problem.
>
> One of the major and fundamental stumbling blocks we've run into is
> that every solution we've looked at so far seems to involve adding
> SE-Linux-specific checks in many places in the code. It would be nice
> if it were possible to use the exist permissions-checking functions
> and have them check a few more things while they're at it, but it's
> looking like that won't be feasible, or at least no one's come up with
> a plausible design yet.

That's not surprising. If you look at the experience from adding access
control hooks to the Linux kernel (both the initial patchset that added
SELinux hooks directly, and the LSM hooks) as well as the XACE hooks added
to X.org, you'll find similar experiences.

> Consequently there are checks spread
> throughout the code, which definitely complicates both validation and
> maintenance. One question I have is - are the places where those
> checks are placed specific to SE-Linux, or would they be applicable to
> any sort of label-based MAC?
>
My guess would be most of them are applicable to most sorts of label-based
MAC. While LSM needed work to be used by the path-based systems out there,
SMACK (which uses labels of a different ilk) required very few (maybe no?)
changes to LSM to work. Looking through the hooks, I see very little that
doesn't look like it would not work for some other label-based systems
(though possibly not all).

Thanks,
Chad Sellers

On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote:
> On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> One of the major and fundamental stumbling blocks we've run into is
> >> that every solution we've looked at so far seems to involve adding
> >> SE-Linux-specific checks in many places in the code. It would be nice
> >> if it were possible to use the exist permissions-checking functions
> >> and have them check a few more things while they're at it, but it's
> >> looking like that won't be feasible, or at least no one's come up with
> >> a plausible design yet.
> >
> > I don't think that it's about SELinux. The real issue here is that
> > KaiGai-san is about a mile out in front of the PG hackers community
> > in terms of his ambitions for the scope of what can be controlled by
> > security policy. If the patch were only doing what the community has
> > actually agreed to, there would be little need for it to touch anything
> > but the aclcheck functions.
> >
> > Now I recognize that a large part of the potential attraction in this
> > for the security community is exactly the idea of having fine-grain
> > security control. But if you ever want anything significantly different
> > from SQL-standard permission mechanisms, there's going to have to be a
> > whole lot more work done. Basically, nobody in the PG community has got
> > any confidence either in the overall design or the implementation
> > details for locking things down that aren't already controlled by SQL
> > permission mechanisms.
>
> I think that's basically right. Further, I think this is basically a
> resource issue. If you were inclined to spend a large amount of your
> time on this problem, you could either gain confidence in the present
> design and implementation or come up with a new one in which you did
> have confidence. But it doesn't seem important enough to you (or your
> employer) for the amount of time it would take, so you're not. I
> think there are other committers and community members in a similar
> situation - basically all of them.
>
> ...Robert
>

I have to agree with Chad (downthread) that I don't see much in KaiGai's
hook patch that prevents its use by other security models. I will say
though one thing that might have been done wrong was with how it was
presented. In actuality his patch set is two projects (at least). The
first is the framework. So I think the goal should have been to get the
framework integrated first and then work on the SELinux module after
that. The framework patch alone consists of at least 4 sets of logical
changes that could have been separated to make review easier. Once the
framework was in, work could be done to get the SELinux module in while
reducing overhead from the case where no module is loaded.

So with regard to confidence in the design I think that part of the
reason for the skepticism in the fact that it was such a large code
drop. Even the separated parts were very large. I think if the framework
patches are broken up more logically and in a way that is easier to
discuss then that might help the community get a grasp on what it is
trying to accomplish.

In terms of documentation I was reading through the wiki at
sepgsql.googlecode.com and aside from some wordsmithing/grammar things
it is pretty solid with describing what it is trying to accomplish. One
problem that I see is that at first glance it does appear to be very
SELinux centric. It describes access based on types and SELinux contexts
which is understandable based on the fact that it describes the
framework and the module. Something to note is that the documentation
describes an object model for the program. I think that would be a good
place to focus the discussion with respect to a framework if we decide
to pursue it.

Dave

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> One of the major and fundamental stumbling blocks we've run into is
> that every solution we've looked at so far seems to involve adding
> SE-Linux-specific checks in many places in the code.

I've really got to take exception to this. I've only been following
along and not really participating because, to be honest, I'm frustrated
with how this has gone down. In the end there were at least two
patches, in my view, that *didn't* involve adding SE-Linux-specific
checks everywhere. The patch that I reviewed that got thrown out by
Tom, and the original PGACE framework. Both of those added alot of
*hooks*, because they were necessary, but nothing made those hooks
particularly "SELinux-specifc". We're hearing alot about things being
SELinux-specific from people who also profess to not know SELinux.

Indeed, as I recall, the patch I reviewed was primairly trying to just
addess pulling out the hooks necessary for the existing PostgreSQL
security model. Very little of it was SE-Linux specific *anything*.

I contend that while the specific hooks which would be added *in
places that don't already have checks* (in most places, the hook was
added to replace an existing check) are hooks that then make sense
for SELinux, they would also make sense for other frameworks. They
may also not be a complete list, but once the *framework* is in
place, adding new hooks (presuming another model would like a hook
somewhere that SELinux and the existing PG security framework don't)
should not require some kind of forklift upgrade.

> It would be nice
> if it were possible to use the exist permissions-checking functions
> and have them check a few more things while they're at it, but it's
> looking like that won't be feasible, or at least no one's come up with
> a plausible design yet.

The problem is that the existing permissions-checking is done all over
the place. That's not ideal from the get-go, in my opinion.
Unfortuantely, when we moved all of the permissions-checking to a single
place, it required knowing about alot of the backend, which Tom took
exception to. I agree that's frustrating, but I don't see it as a
particular reason to throw out the entire concept of a modular security
framework. Perhaps we need to better expose just those pieces the
security framework cares about from the other parts of the backend- it's
entirely likely that the reason it has to know about everything is that,
due to where all the existing security checks are, they just (ab)used
the fact that they had access to that information at hand for that
object type.

> Consequently there are checks spread
> throughout the code, which definitely complicates both validation and
> maintenance. One question I have is - are the places where those
> checks are placed specific to SE-Linux, or would they be applicable to
> any sort of label-based MAC?

The patch which I worked with Kaigai on was specifically geared to first
try to get a patch which addressed the existing PG security model in a
modular way, to allow additional hooks to be added later in places which
needed them, and to provide the information for other models to make a
decision about the permission. I don't feel it was particularly
SE-Linux specific at all, but rather a first step towards being able to
support something beyond the model we have today (anything..).

Thanks,

Stephen

On Tue, Dec 8, 2009 at 2:50 PM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
> On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote:
>> On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> >> One of the major and fundamental stumbling blocks we've run into is
>> >> that every solution we've looked at so far seems to involve adding
>> >> SE-Linux-specific checks in many places in the code.  It would be nice
>> >> if it were possible to use the exist permissions-checking functions
>> >> and have them check a few more things while they're at it, but it's
>> >> looking like that won't be feasible, or at least no one's come up with
>> >> a plausible design yet.
>> >
>> > I don't think that it's about SELinux.  The real issue here is that
>> > KaiGai-san is about a mile out in front of the PG hackers community
>> > in terms of his ambitions for the scope of what can be controlled by
>> > security policy.  If the patch were only doing what the community has
>> > actually agreed to, there would be little need for it to touch anything
>> > but the aclcheck functions.
>> >
>> > Now I recognize that a large part of the potential attraction in this
>> > for the security community is exactly the idea of having fine-grain
>> > security control.  But if you ever want anything significantly different
>> > from SQL-standard permission mechanisms, there's going to have to be a
>> > whole lot more work done.  Basically, nobody in the PG community has got
>> > any confidence either in the overall design or the implementation
>> > details for locking things down that aren't already controlled by SQL
>> > permission mechanisms.
>>
>> I think that's basically right.  Further, I think this is basically a
>> resource issue.  If you were inclined to spend a large amount of your
>> time on this problem, you could either gain confidence in the present
>> design and implementation or come up with a new one in which you did
>> have confidence.  But it doesn't seem important enough to you (or your
>> employer) for the amount of time it would take, so you're not.  I
>> think there are other committers and community members in a similar
>> situation - basically all of them.
>
> I have to agree with Chad (downthread) that I don't see much in KaiGai's
> hook patch that prevents its use by other security models. I will say
> though one thing that might have been done wrong was with how it was
> presented. In actuality his patch set is two projects (at least). The
> first is the framework. So I think the goal should have been to get the
> framework integrated first and then work on the SELinux module after
> that. The framework patch alone consists of at least 4 sets of logical
> changes that could have been separated to make review easier. Once the
> framework was in, work could be done to get the SELinux module in while
> reducing overhead from the case where no module is loaded.

I can say from experience that this project is very skeptical of
frameworks that aren't accompanied by at least one, and preferably
multiple, working implementations. So there is a bit of a chicken and
egg problem here. What can sometimes work is to say, look, here's a
place where I can put a hook and later I will do something complex
with it but here are a couple of relatively simple but useful examples
to get started. The examples form the justification for the commit
because they are independently useful, but they are much simpler than
what the framework may eventually end up being used for.

I don't believe that this approach is feasible for SE-PostgreSQL. A
simple version of label security is still going to be very
complicated, and there are probably even fewer customers for such a
thing than there are for SE-PostgreSQL.

> So with regard to confidence in the design I think that part of the
> reason for the skepticism in the fact that it was such a large code
> drop. Even the separated parts were very large.

Definitely true.

> I think if the framework
> patches are broken up more logically and in a way that is easier to
> discuss then that might help the community get a grasp on what it is
> trying to accomplish.

Maybe, maybe not. Nobody's going to commit anything unless it's a
complete feature. It can be a cut-down feature, but it has to be of
independent use. If there are parts that can be peeled off of
SE-PostgreSQL and committed independently to some good benefit, then I
think that's a great idea. But if it's just a separation of the patch
for clarity, I don't think there's much value in that.

> In terms of documentation I was reading through the wiki at
> sepgsql.googlecode.com and aside from some wordsmithing/grammar things
> it is pretty solid with describing what it is trying to accomplish. One
> problem that I see is that at first glance it does appear to be very
> SELinux centric. It describes access based on types and SELinux contexts
> which is understandable based on the fact that it describes the
> framework and the module. Something to note is that the documentation
> describes an object model for the program. I think that would be a good
> place to focus the discussion with respect to a framework if we decide
> to pursue it.

I have proofread earlier versions of the docs and found them
inadequate. There were language issues, but the bigger problem was
that they were both too specific and yet not sufficiently detailed.
For example, they'd say "install X package on Red Hat". Well, what if
I'm not on Red Hat? The on the other hand they'd say "this GUC
enables mcstrans" which means nothing to me. I think this has been
improved somewhat in more recent version, but clearly we need (1) good
developer documentation, so someone other than KaiGai has a chance of
maintaining the code and keeping it correct as other things are
changed; (2) user documentation, so that someone can read the "feature
story" for this capability; and (3) reference documentation,
cross-referenced with the user documentation.

Having said that, fixing the documentation won't get this patch
committed, though it's certainly a step in the right direction. For
that we need a committer-owner.

...Robert

On Tue, 2009-12-08 at 15:24 -0500, Stephen Frost wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> > One of the major and fundamental stumbling blocks we've run into is
> > that every solution we've looked at so far seems to involve adding
> > SE-Linux-specific checks in many places in the code.
>
> I've really got to take exception to this. I've only been following
> along and not really participating because, to be honest, I'm frustrated
> with how this has gone down. In the end there were at least two
> patches, in my view, that *didn't* involve adding SE-Linux-specific
> checks everywhere. The patch that I reviewed that got thrown out by
> Tom, and the original PGACE framework. Both of those added alot of
> *hooks*, because they were necessary, but nothing made those hooks
> particularly "SELinux-specifc". We're hearing alot about things being
> SELinux-specific from people who also profess to not know SELinux.
>
> Indeed, as I recall, the patch I reviewed was primairly trying to just
> addess pulling out the hooks necessary for the existing PostgreSQL
> security model. Very little of it was SE-Linux specific *anything*.
>
> I contend that while the specific hooks which would be added *in
> places that don't already have checks* (in most places, the hook was
> added to replace an existing check) are hooks that then make sense
> for SELinux, they would also make sense for other frameworks. They
> may also not be a complete list, but once the *framework* is in
> place, adding new hooks (presuming another model would like a hook
> somewhere that SELinux and the existing PG security framework don't)
> should not require some kind of forklift upgrade.
>
> > It would be nice
> > if it were possible to use the exist permissions-checking functions
> > and have them check a few more things while they're at it, but it's
> > looking like that won't be feasible, or at least no one's come up with
> > a plausible design yet.
>
> The problem is that the existing permissions-checking is done all over
> the place. That's not ideal from the get-go, in my opinion.
> Unfortuantely, when we moved all of the permissions-checking to a single
> place, it required knowing about alot of the backend, which Tom took
> exception to. I agree that's frustrating, but I don't see it as a
> particular reason to throw out the entire concept of a modular security
> framework. Perhaps we need to better expose just those pieces the
> security framework cares about from the other parts of the backend- it's
> entirely likely that the reason it has to know about everything is that,
> due to where all the existing security checks are, they just (ab)used
> the fact that they had access to that information at hand for that
> object type.
>
> > Consequently there are checks spread
> > throughout the code, which definitely complicates both validation and
> > maintenance. One question I have is - are the places where those
> > checks are placed specific to SE-Linux, or would they be applicable to
> > any sort of label-based MAC?
>
> The patch which I worked with Kaigai on was specifically geared to first
> try to get a patch which addressed the existing PG security model in a
> modular way, to allow additional hooks to be added later in places which
> needed them, and to provide the information for other models to make a
> decision about the permission. I don't feel it was particularly
> SE-Linux specific at all, but rather a first step towards being able to
> support something beyond the model we have today (anything..).
>
> Thanks,
>
> Stephen

I think what makes people think that the changes are SELinux specific is
that the examples given use SELinux contexts. I think it should be made
clear that saying that in the PG there is a database object and we want
to mediate access to create database objects is not SELinux or even MAC
model specific (asside from labels). However to say that a program
labeled myapp_t can connect to the database and create a table and when
its created its labeled mytable_t that would be something SELinux
specific. The framework idea separates that. It says hey here are the
objects in the system and here are the actions on them that we want to
mediate. I will admit that since SELinux is the driving MAC model for
the framework you're going to find that the objects and permissions are
the ones that it wants to control. However like Steven said, adding a
hook later on or having a model not use a hook is not a Herculean task.
We've proven time and time again with the LSM framework that when a
feature is added it is trivial to introduce a new hook to mediate it or
to place an existing hook. I understand that PostgreSQL is a fast moving
target with a large developer base but so is the Linux Kernel and a
similar framework has been working there for years now.

Dave

On mån, 2009-12-07 at 17:33 +0100, Martijn van Oosterhout wrote:
> On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote:
> > > Given the extreme patience and diligence exhibited by KaiGai, I
> > > hesitate to say this, but it seems to me that this would be
> > > critically important for the long term success of this feature. I
> > > have no idea how much work it would be to make the interface to the
> > > external security system pluggable, but if it's at all feasible, I
> > > think it should be done.
> >
> > This is how the code was developed initially -- the patch was called
> > PGACE and SELinux was but the first implementation on top of it.
>
> I find it astonishing that after SE-PgSQL was implemented on top of a
> pluggable system (PGACE) and this system was removed at request of the
> "community" [1] that at this late phase people are suggesting it needs
> to be added back again. Havn't the goalposts been moved enough times?

PGACE wasn't a plugin system. It was an API inside the core code. If
it had been a plugin system, this would have been much easier, because
the plugin itself could have been developed independently.

On mån, 2009-12-07 at 11:45 -0500, Chris Browne wrote:
> I feel about the same way about this as I did about the adding of
> "native Windows" support; I'm a bit concerned that this could be a
> destabilizing influence. I was wrong back then; the Windows support
> hasn't had the ill effects I was concerned it might have.

Windows support certainly has had ill effects, but the benefits of
supporting Windows clearly outweigh that.

On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote:
[snip...]
>
> I can say from experience that this project is very skeptical of
> frameworks that aren't accompanied by at least one, and preferably
> multiple, working implementations. So there is a bit of a chicken and
> egg problem here. What can sometimes work is to say, look, here's a
> place where I can put a hook and later I will do something complex
> with it but here are a couple of relatively simple but useful examples
> to get started. The examples form the justification for the commit
> because they are independently useful, but they are much simpler than
> what the framework may eventually end up being used for.
>
> I don't believe that this approach is feasible for SE-PostgreSQL. A
> simple version of label security is still going to be very
> complicated, and there are probably even fewer customers for such a
> thing than there are for SE-PostgreSQL.
>

Ok if it is a chicken and egg problem then we need to find a smaller
egg. I agree that having a huge patch set isn't ideal which is why I
understand the desire to have KaiGai cut back his patches. However the
patches he is putting forward from what I've gathered have no row based
labeling and no MAC enforcement. I can understand if you want to cut
back the object model so you're not mediating every object in the system
but cutting those two features make it unusable by the customers we have
who want to use it.

> > So with regard to confidence in the design I think that part of the
> > reason for the skepticism in the fact that it was such a large code
> > drop. Even the separated parts were very large.
>
> Definitely true.
>
> > I think if the framework
> > patches are broken up more logically and in a way that is easier to
> > discuss then that might help the community get a grasp on what it is
> > trying to accomplish.
>
> Maybe, maybe not. Nobody's going to commit anything unless it's a
> complete feature. It can be a cut-down feature, but it has to be of
> independent use. If there are parts that can be peeled off of
> SE-PostgreSQL and committed independently to some good benefit, then I
> think that's a great idea. But if it's just a separation of the patch
> for clarity, I don't think there's much value in that.

I don't think it would be just for clarity. I know that not all open
source communities are the same so I'll try to leave the anecdotal
evidence light. When submit patches for the Linux Kernel we take a
single feature and structure them as self contained logical changes.
Separating the changes logically doesn't just improve clarity but also
makes it easy to cherry pick features that can be useful on their own.
Just because the framework and the SEPostgreSQL features would be two
patch sets doesn't mean they aren't being developed in parallel. It
looks to me that we're in the same boat we were in with SELinux. We had
the feature and proposed it and someone brought up "well what about
other security models". So time was spent developing a framework that
everyone could use and as that was being done the SELinux patches were
modified to use this new framework. They were two separate features
developed in tandem. If we do it right the SEPostgreSQL code will be
isolated from the framework and we can spend time putting the framework
in and just plug in the specific security module when time comes. The
X-ACE work went in to X before the corresponding SELinux Flask module
for it and I don't believe LSM and SELinux went into the same merge
window as well.

>
> I have proofread earlier versions of the docs and found them
> inadequate. There were language issues, but the bigger problem was
> that they were both too specific and yet not sufficiently detailed.
> For example, they'd say "install X package on Red Hat". Well, what if
> I'm not on Red Hat? The on the other hand they'd say "this GUC
> enables mcstrans" which means nothing to me. I think this has been
> improved somewhat in more recent version, but clearly we need (1) good
> developer documentation, so someone other than KaiGai has a chance of
> maintaining the code and keeping it correct as other things are
> changed; (2) user documentation, so that someone can read the "feature
> story" for this capability; and (3) reference documentation,
> cross-referenced with the user documentation.
>
> Having said that, fixing the documentation won't get this patch
> committed, though it's certainly a step in the right direction. For
> that we need a committer-owner.
>

True but hopefully proper documentation will help someone decide that
they have enough information to take on that position.

> ...Robert

On Tue, Dec 8, 2009 at 3:24 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> One of the major and fundamental stumbling blocks we've run into is
>> that every solution we've looked at so far seems to involve adding
>> SE-Linux-specific checks in many places in the code.
>
> I've really got to take exception to this.  I've only been following
> along and not really participating because, to be honest, I'm frustrated
> with how this has gone down.  In the end there were at least two
> patches, in my view, that *didn't* involve adding SE-Linux-specific
> checks everywhere.  The patch that I reviewed that got thrown out by
> Tom, and the original PGACE framework.  Both of those added alot of
> *hooks*, because they were necessary, but nothing made those hooks
> particularly "SELinux-specifc".  We're hearing alot about things being
> SELinux-specific from people who also profess to not know SELinux.

Sorry. I spent a lot of time for both CommitFest 2008-11 and
CommitFest 2009-07 in the hopes of getting something committable, and
I wasn't successful. I'm just at the end of my rope. It seems fairly
clear that Tom isn't going to commit any piece of SE-PostgreSQL at
all, ever. So who's going to do it? It doesn't make any sense to
continue trucking along with this patch into the indefinite future if
it has no hope of being committed.

Frankly, I think this comes down to money. There are several
PostgreSQL companies which employ very capable PostgreSQL committers.
When someone is willing to pony up enough money to get those people
interested (as, I gather, has happened with block-checksumming) then
this will happen. Until then, I don't believe anyone is going to
volunteer to be responsible for a 10,000-line patch in their free
time. Tom is the only one crazy enough for that, and he said no.

The next time someone submits a huge, unsolicited patch to do
ANYTHING, we should do them a favor and tell them this up front,
rather than a year and a half later. Then they could have the
appropriate conversations with the appropriate people and determine
whether to budget for it or give up. What has happened with this
patch has not served KaiGai well, or improved the image of this
community.

> I agree that's frustrating, but I don't see it as a
> particular reason to throw out the entire concept of a modular security
> framework.

I don't either. There were certainly technical things in the previous
patch that could stand to have been improved, and I think the general
approach has some potential.

...Robert

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> PGACE wasn't a plugin system. It was an API inside the core code. If
> it had been a plugin system, this would have been much easier, because
> the plugin itself could have been developed independently.

Well, it should certainly have used function pointers or something to
allow better pluggability, but that would have been a trivial change.
I don't believe that doing so would have made development any easier.
The real problem in all this is to answer the question "do we have the
right hooks in the right places?". Whether the hooks lead to function
pointers or hard-wired calls doesn't enter into that. Moreover, since
we can confidently say that all the early answers will be "no", it would
be a serious mistake to try to develop the plugin independently.
Having to keep two independent sets of source code in sync would waste
a lot of effort every time you realized you needed to adjust the hook
definitions. Once you'd gotten to a releasable state maybe you could
assume the hook definitions would become stable, but right now I have no
confidence in that at all.

regards, tom lane

On Tue, 2009-12-08 at 16:51 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > PGACE wasn't a plugin system. It was an API inside the core code. If
> > it had been a plugin system, this would have been much easier, because
> > the plugin itself could have been developed independently.
>
> Well, it should certainly have used function pointers or something to
> allow better pluggability, but that would have been a trivial change.
> I don't believe that doing so would have made development any easier.
> The real problem in all this is to answer the question "do we have the
> right hooks in the right places?". Whether the hooks lead to function
> pointers or hard-wired calls doesn't enter into that. Moreover, since
> we can confidently say that all the early answers will be "no", it would
> be a serious mistake to try to develop the plugin independently.
> Having to keep two independent sets of source code in sync would waste
> a lot of effort every time you realized you needed to adjust the hook
> definitions. Once you'd gotten to a releasable state maybe you could
> assume the hook definitions would become stable, but right now I have no
> confidence in that at all.
>
> regards, tom lane
>

I disagree with several of your statements above. While the question of
whether or not the hooks are in the right place is up for debate what
the hooks should be is something that I think has been explored pretty
well. The hooks should reflect the object model. Where you need to put
them to enforce permission is a different story.

Also maintaining a module and a framework is not a waste of time. If
your security module has a tremendous code churn when the interface to
the program is modified you should reevaluate your design. Both SELinux
and the Flask X-ACE modules are examples where an existing extension had
a modular framework developed after the fact and easily integrated into
the project. The majority of the work is moving to a framework not
changing function prototypes in code that's already in the framework.

Dave

Robert Haas wrote:
> On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
>> I'd be willing to take a look at the framework and see if it really is
>> SELinux centric. If it is we can figure out if there is a way to
>> accomodate something like SMACK and FMAC. I'd like to hear from someone
>> with more extensive experience with Solaris Trusted Extensions about how
>> TX would make use of this. I have a feeling it would be similar to the
>> way it deals with NFS which is by having the process exist in the global
>> zone as a privileged process and then multi-plexes it to the remaining
>> zones. That way their getpeercon would get a label derived from the
>> zone.
>
> Well, the old patches should still be available in the mailing list
> archives. Maybe going back and looking at that code would be a good
> place to start. The non-ripped-out code has been cleaned up a lot
> since then, but at least it's a place to start.

We can see old branches here:

http://code.google.com/p/sepgsql/source/browse/branches/pgsql-8.3.x/sepgsql/src/backend/security/pgaceHooks.c

But I don't provide this framework for the 8.4.x/8.5.x, because this
idea was rejected in the earlier discussion.
Please consider it represent just a concept.

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

Robert Haas wrote:
> Sorry. I spent a lot of time for both CommitFest 2008-11 and
> CommitFest 2009-07 in the hopes of getting something committable, and
> I wasn't successful. I'm just at the end of my rope. It seems fairly
> clear that Tom isn't going to commit any piece of SE-PostgreSQL at
> all, ever. So who's going to do it? It doesn't make any sense to
> continue trucking along with this patch into the indefinite future if
> it has no hope of being committed.
>
> Frankly, I think this comes down to money. There are several
> PostgreSQL companies which employ very capable PostgreSQL committers.
> When someone is willing to pony up enough money to get those people
> interested (as, I gather, has happened with block-checksumming) then
> this will happen. Until then, I don't believe anyone is going to
> volunteer to be responsible for a 10,000-line patch in their free
> time. Tom is the only one crazy enough for that, and he said no.

I have offered to review/commit the patch. I don't promise my effort
will be pretty, but I will get the job done. I have not started yet
because I think we are still unclear if the feature is worth the
additional code maintenance.

I frankly think the patch should be thought of as the SE-Linux-specific
directory files, which KaiGai can maintain, and the other parts, which I
think I can handle.

> The next time someone submits a huge, unsolicited patch to do
> ANYTHING, we should do them a favor and tell them this up front,
> rather than a year and a half later. Then they could have the
> appropriate conversations with the appropriate people and determine
> whether to budget for it or give up. What has happened with this
> patch has not served KaiGai well, or improved the image of this
> community.

Yes, this has not been our finest hour. :-(

I think the causes have been explained already:

o early patches did not have community buy-in
o we are unclear about the size of the user community
o we are unclear what the end user will want
o the feature is complex
o the features is in an unfamiliar problem-domain

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

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

David P. Quigley wrote:
> So I was reading through a set of slides that KaiGai has and he
> mentioned a May commitfest link and I looked for the comments related to
> his PGACE patches. I've been crawling through the commitfest paces so I
> can figure out what the latest version of the pgace patch is. Does
> anyone know when the patch was reduced to what it is today?

I could salvage a legacy PGACE patch:
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch

However, its code base was v8.4devel, so conflictable to the latest CVS HEAD.
In addition, it contains various kind of concepts within a single patch.
* comprehensive security hooks
* a facility to store security identifier on the header of each row
* a facility to translate between security identifier (int) and
security context (text)
* "security_context" writable system column support.

From the current perspective, we can understand these features should be
proposed as separated features. But I was young.

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

David P. Quigley wrote:
> I understand that PostgreSQL is a fast moving target with a large developer base but so is the Linux Kernel and a
> similar framework has been working there for years now.
>

It sounds like how you're thinking about this project's development
model is inverted from the reality, and it's import to sort that out
because it really impacts why there's so much resistance here. One
reason the Linux kernel moves so fast because they don't care one lick
for many types of backward compatibility, they'll just change interfaces
as necessary to work around problems. To use the terms of the old 2.4
Linux kernel, there is no "stable" branch development happens against
anymore; just the fast changing unstable one, that if everyone is lucky
eventually converges into some usable versions anyway.

Here, there is zero tolerance for any commit that destabilizes the
codebase even temporarily. Until you get the whole thing sorted out
usefully enough to be shippable quality, you don't go into the main (and
only official) branch.

Also, the PostgreSQL developers like to deliver a stable release and
then change *nothing* to it except to fix bugs, supporting that release
for years. We consider a released piece of software like a contract to
the users, and everyone goes through lots of work to avoid changing
anything unless absolutely necessary. A very large component of the
concern here comes from that mindset. If this goes out, and there's a
fundamental problem with it, this community doesn't even have a good
process to fix that until the next major release, around a year later.
In general, there is no such thing as an upgrade to a stable version
that includes a serious behavior change. Having that happen is
considered a major breakdown in the process, and there's only been a
very small number of such situations in the past, when some just
impossible to work around bug was introduced. Instead, just the
absolute minimum of changes needed to fix bugs are applied to the
stable, shipped versions. If a version ships with a broken enough
behavior, it's quite possible that fixing it cannot be done in a way
that can be distributed and applied via the standard minor version
upgrade procedure used at all.

The idea here is not "if it's not quite right, development is fast so it
will get sorted out eventually". Instead it's "if it's not believed to
be free of non-trivial bugs, don't commit it at all". SEPostgres has
lived in this state for a while now. And it's not known bugs that are
the problem, it's that almost all of the Postgres community can't even
accurately gauge whether there are bugs or not in the code/design, which
is really uncomfortable given how things work here.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

David P. Quigley wrote:
> On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote:
> [snip...]
>> I can say from experience that this project is very skeptical of
>> frameworks that aren't accompanied by at least one, and preferably
>> multiple, working implementations. So there is a bit of a chicken and
>> egg problem here. What can sometimes work is to say, look, here's a
>> place where I can put a hook and later I will do something complex
>> with it but here are a couple of relatively simple but useful examples
>> to get started. The examples form the justification for the commit
>> because they are independently useful, but they are much simpler than
>> what the framework may eventually end up being used for.
>>
>> I don't believe that this approach is feasible for SE-PostgreSQL. A
>> simple version of label security is still going to be very
>> complicated, and there are probably even fewer customers for such a
>> thing than there are for SE-PostgreSQL.
>>
>
> Ok if it is a chicken and egg problem then we need to find a smaller
> egg. I agree that having a huge patch set isn't ideal which is why I
> understand the desire to have KaiGai cut back his patches. However the
> patches he is putting forward from what I've gathered have no row based
> labeling and no MAC enforcement. I can understand if you want to cut
> back the object model so you're not mediating every object in the system
> but cutting those two features make it unusable by the customers we have
> who want to use it.

The coverage of access controls are tradeoff between amount of the
changeset and valuable functionalities, in generally. Ultimately it
is a role of developer to decide what is unseparatable core feture
and what is separatable secondary one.

It is my decision to restrict types of database objects to reduce
burden of reviewers, so the latest one apply SELinux specific access
controls on only databases, schemas, tables and columns.

Even if we have a framework to host label-based MAC, its coverage shall
be unchanged, because comprehensive support at once obviously makes
harder to review.

>>> So with regard to confidence in the design I think that part of the
>>> reason for the skepticism in the fact that it was such a large code
>>> drop. Even the separated parts were very large.
>> Definitely true.
>>
>>> I think if the framework
>>> patches are broken up more logically and in a way that is easier to
>>> discuss then that might help the community get a grasp on what it is
>>> trying to accomplish.
>> Maybe, maybe not. Nobody's going to commit anything unless it's a
>> complete feature. It can be a cut-down feature, but it has to be of
>> independent use. If there are parts that can be peeled off of
>> SE-PostgreSQL and committed independently to some good benefit, then I
>> think that's a great idea. But if it's just a separation of the patch
>> for clarity, I don't think there's much value in that.
>
> I don't think it would be just for clarity. I know that not all open
> source communities are the same so I'll try to leave the anecdotal
> evidence light. When submit patches for the Linux Kernel we take a
> single feature and structure them as self contained logical changes.
> Separating the changes logically doesn't just improve clarity but also
> makes it easy to cherry pick features that can be useful on their own.
> Just because the framework and the SEPostgreSQL features would be two
> patch sets doesn't mean they aren't being developed in parallel. It
> looks to me that we're in the same boat we were in with SELinux. We had
> the feature and proposed it and someone brought up "well what about
> other security models". So time was spent developing a framework that
> everyone could use and as that was being done the SELinux patches were
> modified to use this new framework. They were two separate features
> developed in tandem. If we do it right the SEPostgreSQL code will be
> isolated from the framework and we can spend time putting the framework
> in and just plug in the specific security module when time comes. The
> X-ACE work went in to X before the corresponding SELinux Flask module
> for it and I don't believe LSM and SELinux went into the same merge
> window as well.

It is necessary to deploy the framework and SELinux support at same time
or the framework earlier than SELinux? We can organize a common framework
when the second security module will come in. From our experience, it may
need similar security hooks on same or similar strategic points.

In the development history, the code size and complexity had been a matter
for inclusion. I also think the idea to invoke security modules via mac
framework is right approach, but it increases the initial code size compared
to the current approach in spite of even user visible whorth.

>> I have proofread earlier versions of the docs and found them
>> inadequate. There were language issues, but the bigger problem was
>> that they were both too specific and yet not sufficiently detailed.
>> For example, they'd say "install X package on Red Hat". Well, what if
>> I'm not on Red Hat? The on the other hand they'd say "this GUC
>> enables mcstrans" which means nothing to me. I think this has been
>> improved somewhat in more recent version, but clearly we need (1) good
>> developer documentation, so someone other than KaiGai has a chance of
>> maintaining the code and keeping it correct as other things are
>> changed; (2) user documentation, so that someone can read the "feature
>> story" for this capability; and (3) reference documentation,
>> cross-referenced with the user documentation.
>>
>> Having said that, fixing the documentation won't get this patch
>> committed, though it's certainly a step in the right direction. For
>> that we need a committer-owner.
>>
>
> True but hopefully proper documentation will help someone decide that
> they have enough information to take on that position.

If you have any concern about documentations, I very welcome any feedbacks.

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

2009/12/9 Bruce Momjian <bruce(at)momjian(dot)us>:
> I frankly think the patch should be thought of as the SE-Linux-specific
> directory files, which KaiGai can maintain, and the other parts, which I
> think I can handle.

I think that's a horribly bad idea.

We have already got a similar issue with ECPG, which clearly stagnates
whenever Michael is busy and don't have time to go through the
patches. Because it's "his code", and nobody else knows how to and/or
cares to maintain it. And this is just a single piece of the frontend
that doesn't affect anything else.

If you want to do something similar for sepg, then sepg needs to be
turned into a full plugin system, where the plugin is a completely
separate thing. In which case the plugin can be developed separately,
for example on pgfoundry (and be considered to merge later, if we
want, but not necessarily ever since it has a narrow user base).

I haven't looked at the patch properly for quite a while, but I
imagine turning it into such a plugin is not feasible. Because if it
is, why haven't this been done already? :) But if it is, perhaps that
is something we should consider, since it lessens the maintenance
burden into "just" the API (which is still a huge burden compared to
many of our APIs, but it is a lot less than what the patch is now)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Stephen Frost wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> One of the major and fundamental stumbling blocks we've run into is
>> that every solution we've looked at so far seems to involve adding
>> SE-Linux-specific checks in many places in the code.
>
> I've really got to take exception to this. I've only been following
> along and not really participating because, to be honest, I'm frustrated
> with how this has gone down. In the end there were at least two
> patches, in my view, that *didn't* involve adding SE-Linux-specific
> checks everywhere. The patch that I reviewed that got thrown out by
> Tom, and the original PGACE framework. Both of those added alot of
> *hooks*, because they were necessary, but nothing made those hooks
> particularly "SELinux-specifc". We're hearing alot about things being
> SELinux-specific from people who also profess to not know SELinux.
>
> Indeed, as I recall, the patch I reviewed was primairly trying to just
> addess pulling out the hooks necessary for the existing PostgreSQL
> security model. Very little of it was SE-Linux specific *anything*.
>
> I contend that while the specific hooks which would be added *in
> places that don't already have checks* (in most places, the hook was
> added to replace an existing check) are hooks that then make sense
> for SELinux, they would also make sense for other frameworks. They
> may also not be a complete list, but once the *framework* is in
> place, adding new hooks (presuming another model would like a hook
> somewhere that SELinux and the existing PG security framework don't)
> should not require some kind of forklift upgrade.

Basically, I don't think it is a bad idea to provide a framework to host
multiple label-based security mechanisms, because they have same origin
so they have similar features, such as security label and policy.

However, we have a tradeoff betweem an ideal image (multiple enhanced
security stuff can be launched via common hooks) and amount of changeset.
The latest SE-PgSQL/Lite patch support only four kind of database objects
(databases, schemas, tables and columns), so it puts security hooks on
the strategic points corresponding to these objects, such as createdb().

If we simply replace the invocations by the common hooks, coverage of the
framework will be restricted to these four objects. Is it possible to call
them as a framework?
If it will be comprehensive from the first, we shall face a nightmare again.

I think we can replace the sepgsql_*() invocations by the framework
when the second enhancement (such as Solaris-TX?) will come in.
Note that label-based security has historically same origin, so we
can expect much smaller arrangement than integration DAC and MAC.

>> Consequently there are checks spread
>> throughout the code, which definitely complicates both validation and
>> maintenance. One question I have is - are the places where those
>> checks are placed specific to SE-Linux, or would they be applicable to
>> any sort of label-based MAC?
>
> The patch which I worked with Kaigai on was specifically geared to first
> try to get a patch which addressed the existing PG security model in a
> modular way, to allow additional hooks to be added later in places which
> needed them, and to provide the information for other models to make a
> decision about the permission. I don't feel it was particularly
> SE-Linux specific at all, but rather a first step towards being able to
> support something beyond the model we have today (anything..).

Right, the default PG model has been already comprehensive, and has
a different origin from label-based securities, so we needed massive
changeset to organize both of DAC (the default PG model) and MAC into
a common security framework.

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

On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> 2009/12/9 Bruce Momjian <bruce(at)momjian(dot)us>:
>> I frankly think the patch should be thought of as the SE-Linux-specific
>> directory files, which KaiGai can maintain, and the other parts, which I
>> think I can handle.
>
> I think that's a horribly bad idea.

Me, too. The ECPG comparison is apt, except that this code is far
more deeply integrated into core. The idea that the SE-Linux
directory files can be maintained separately from the "other parts"
does not seem realistic to me. The problems that are going to occur
here are things like: somebody wants to rearrange some part of the
permissions checking for some reason. So they move a bunch of code
around and break SE-PostgreSQL. Someone has to review that patch and
understand the danger it causes. That's going to require
understanding both the SE-PostgreSQL-specific files and the other
parts, and the relationship between the two of them.

...Robert