Re: Updates of SE-PostgreSQL 8.4devel patches (r1710) - Mailing list pgsql-hackers

Ron Mayer wrote:
> Alvaro Herrera wrote:
>> Gregory Stark escribió:
>>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>>
>>>> KaiGai Kohei wrote:
>>>>>  * [..feature description..]
>>>> This again falls into the category of trying to have more fine-grained
>>>> permissions than vanilla PostgreSQL has....
>>> Would it make sense to instead of removing and deferring pieces bit by bit to
>>> instead work the other way around? Extract just the part of the patch that
>>> maps SELinux capabilities to Postgres privileges as a first patch? Then
>>> discuss any other parts individually at a later date? 
>> I think that makes sense.  Implement just a very basic core in a first
>> patch, and start adding checks slowly, one patch each.  We have talked
>> about "incremental patches" in the past.
> 
> +1 from an end-user's point of view too.
> 
> I'm quite aware of the postgres privileges, and if there were a MAC
> system of enforcing those I'd be reasonably likely to enable them
> right away.
> 
> On the other hand, if SEPostgres initially comes with a different set
> of privileges that don't map to what I'm already using, I'm much less
> likely to spend the time to figure out the two different systems.

I cannot update whole of the wikipage yet, but updated some of descriptions
in object classes and permission.  http://wiki.postgresql.org/wiki/SEPostgreSQL#Object_classes_and_permission

Some of permissions are mapped to the vanilla PostgreSQL privileges,
and some of them are not so.

* ACL_INSERT The db_table:{insert} and db_column:{insert} for all the target columns are checked. The table-level
permissiondoes not override column-level permission, so the client need to have privileges for both of objects. It is
sameas other permissions.
 

* ACL_SELECT The db_table:{select} and db_column:{select} for all the target columns are checked. But it applies
db_table:{lock}on LockTableCommand().
 

* ACL_UPDATE The db_table:{update} and db_column:{update} for all the target columns are checked.

* ACL_DELETE The db_table:{delete} is also checked. No column-level checks here.

* ACL_TRUNCATE The db_table:{delete} is also checked. SE-PostgreSQL does not discriminate between TRUNCATE and DELETE.

* ACL_REFERENCES
* ACL_TRIGGER SE-PostgreSQL does not care about these privileges. But, it checks db_procedure:{execute} on trigger
invocationtime, and it also checks db_table:{select} on checks of FK constraint within its secondary SQL execution.
 

* ACL_EXECUTE The db_procedure:{execute} is also checked. This check is embedded within pg_proc_ackcheck().

* ACL_USAGE
* ACL_CREATE
* ACL_CREATE_TEMP SE-PostgreSQL does not care about there privileges.

* ACL_CONNECT The db_database:{access} is also checked. This check is embedded within pg_database_aclcheck().

* ACL_SELECT_FOR_UPDATE The db_table:{lock} should be also checked, but ...

* database superuser privilege The db_database:{superuser} newly added should be also checked.

In addition, SE-PostgreSQL defines and users some of new privileges.

* db_xxx:{relabelfrom} and db_xxx:{relabelto} It is checked when the security context of database objects are changed.

* db_xxx:{create} It is typically checked when CREATE TABLE and others. SE-PostgreSQL assigns a default security
contexton the table and columns newly created, if user does not give any security context explicitly. Then, it checks
whetherthe user have db_xxx:{create} privileges on the tables/columns/etc labeled as the security context, or not.
 

* db_xxx:{setattr}
* db_xxx:{drop} It is typically cheched when ALTER/DROP TABLE and others. The vanilla PostgreSQL checks user's
privilegesbased on the ownership, but SE-PostgreSQL does not consider the concept of owner due to its MAC policy. These
permissionare checked based on the security context assigned to the target objects.
 

* db_procedure:{entrypoint} SE-PostgreSQL allows client to change its privilege during execution of certain procedures
(calledas "trusted procedure"). It checks this permission when user tries to invoke trusted procedure. The vanilla
PostgreSQLdoes not have similar ACL, but it concept it similar to security definer or setuid on operating system.
 


> And I do see row-level restrictions (and the other access restrictions
> mentioned in this thread) as quite orthogonal to MAC vs DAC. Would it
> be cool to have row-level permissions in postgres?  Sure, as an abstract
> concept.   Do I have any use for them?   Seeing that I'm getting by
> without them, the answer must be "not now".

We defined six permissions for row-level, but not used (included) now.

* db_tuple:{relabelfrom}
* db_tuple:{relabelto}
* db_tuple:{select}
* db_tuple:{update}
* db_tuple:{insert}
* db_tuple:{delete}

As SE-PostgreSQL doing on any other database object, it (can) assigns
a default security context on the tuple newly inserted, if user does
not given any security context explicitly.
Then, it checks db_tuple:{insert} permission on them.
Do you need explanation for any other permissions on db_tuple class?

Thanks,

>> We wouldn't get "unbreakable PostgreSQL" in a single commit, but we
>> would at least start moving.
>>
>> The good thing about having started in the opposite direction is that by
>> now we know that the foundation APIs are good enough to build the
>> complete feature.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>