Re: SE-PostgreSQL Specifications - Mailing list pgsql-hackers

Martijn van Oosterhout wrote:
> On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
>> Here is the initial draft of SE-PostgreSQL specifications:
>>
>>   http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
> 
> Hey, this is really cool. Think it is a nice introduction. Fixed some
> of the really obvious language stuff and an example but the English is
> quite good.

Thanks, but I found an incorrect change at the trusted procedure section.

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

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

This example intends to assign "secret" label on the credit column,
not whole of the table. Note that the default security context shall
be assigned on the table and rest of columns in this case.

| For example, when the customer table is defined as follows,
| unprivileged users cannot see the contents of customer.credit
| because it is labeled as sepgsql_secret_table_t which means
| all the accesses are denied from confined domains.

Is the description inadequate to note the example tries to assign
a certain security context on the customer.credit column?


BTW, in the later case, the table is labeled as "secret", then columns
inherit table's security context in the default, so the table and all
the columns are labeled as "secret".

> One thing I know people are going to ask: why did you use names like
> "create" and "delete" and not the usual names that postgresql itself
> uses. I suspect the answer is because that's the standard naming used
> in SELinux, but I think you need to spell that out somewhere.
> 
> The same for the db_* convention. Do you have a reference to naming
> conventions for SELinux permissions?

http://oss.tresys.com/repos/refpolicy/trunk/policy/flask/access_vectors

All the object classes managed in userspace object manager have its prefix.
For example, X-window objects has x_* prefix.
Kenel objects don't have any prefix, such as "file".

Referring the other base object classes, it uses "create", "getattr",
"setattr", "relabelfrom" and "relabelto" commonly. However, a permission
to remove the object itself is named reflecting to the characteristics of
the object.
For example, file:{unlink} and ipc:{destroy} mean a permission to remove
itself. I believe "drop" is an appropriate naming for database objects.

TODO: add description at the "Object classes and permissions" why object     classes are prefixed by db_*

> I need to think it over some more, but it's a really good start.
> 
> Have a nice day,


-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>