Ron Mayer wrote:
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas <heikki.linnakan...@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 permission does not override
column-level permission, so the client need to have privileges
for both of objects. It is same as 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 invocation time,
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 context on the table and
columns newly created, if user does not give any security context
explicitly.
Then, it checks whether the 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 privileges based on the ownership,
but SE-PostgreSQL does not consider the concept of owner due to its
MAC policy. These permission are 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 (called as "trusted procedure"). It checks this
permission when user tries to invoke trusted procedure.
The vanilla PostgreSQL does 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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
