Sorry for my late updates.
I tried to update list of permissions that sepgsql expects, even though
the description might be still a bit rough... https://wiki.postgresql.org/wiki/SEPostgreSQL_Permissions
Set of permissions are defined for each object class that represents
a particular database object. This list summarize all the defined
permissions and introduction of the case when it shall be checked.
Right now, the list of permissions are based on the latest selinux
policy release at 20120725, but db_materialized_view class will
be (probably) added in the future release somewhere in 2013.
So, I added a short mention of this.
My 2/3 and 3.3 patch try to add support "search" permission of
db_schema class and "execute" permission of db_procedure class.
It tries to implement relevant checks, but not supported yet.
Does the permission list help to understand what does these
patch try to tackle?
Thanks,
2013/1/29 Simon Riggs <simon@2ndquadrant.com>:
> On 29 January 2013 14:39, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> 2013/1/29 Simon Riggs <simon@2ndquadrant.com>:
>>> On 29 January 2013 13:30, Kohei KaiGai <kaigai@kaigai.gr.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
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
