Re: [sepgsql 2/3] Add db_schema:search permission checks

On 29 January 2013 14:39, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 2013/1/29 Simon Riggs <simon(at)2ndquadrant(dot)com>:
>> On 29 January 2013 13:30, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>
>>> It makes unavailable to control execution of
>>> functions from viewpoint of selinux, and here is no way selinux
>>> to prevent to execute functions defined by other domains, or
>>> others being not permitted.
>>> Also, what we want to do is almost same as existing permission
>>> checks, except for its criteria to make access control decision.
>>
>> Do you have a roadmap of all the things this relates to?
>>
>> If selinux has a viewpoint, I'd like to be able to see a list of
>> capabilities and then which ones are currently missing. I guess I'm
>> looking for external assurance that someone somewhere needs this and
>> that it fits into a complete overall plan of what we should do. Just
>> like we are able to use SQLStandard as a guide as to what we need to
>> implement, we would like something to refer back to. Does this have a
>> request id, specification document page number or whatever?
>>
> I previously made several wiki pages for reference of permissions
> to be checked, but it needs maintenance works towards the latest
> state, such as newly added permissions.
> http://wiki.postgresql.org/wiki/SEPostgreSQL_References
>
> Even though selinuxproject.org hosts permission list, it is more
> rough than what I described at wiki.postgresql.org.
> http://www.selinuxproject.org/page/ObjectClassesPerms#Database_Object_Classes
>
> Unlike SQL standard, we have less resource to document its spec
> being validated by third persons. However, it is a reasonable solution
> to write up which permission shall be checked on which timing.
>
> Let me revise the above wikipage to show my overall plan.

OK, that's looking like a good and useful set of info.

What we need to do is to give the SELinux API a spec/version number
(yes, the SELinux one) and then match what PostgreSQL implements
against that, so we can say we are moving towards spec compliance with
1.0 and we have a list of unimplemented features...

That puts this in a proper context, so we know what we are doing, why
we are doing it and also when we've finished it. And also, how to know
what future external changes will cause additional work.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services