Re: [v9.2] Object access hooks with arguments support (v1) - Mailing list pgsql-hackers

2011/10/21 Robert Haas <robertmhaas@gmail.com>:
> On Fri, Oct 21, 2011 at 12:44 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> I had checked my older implementation based on 8.4.x or 9.0.x that
>> includes all the features that I want to implement.
>> At least, it does not require so much different information from ones
>> needed by DAC model, although SELECT INTO was an exception.
>> It might be quite natural because both works similar things.
>
> OK.  It seems like it might be helpful to put together a list of all
> of the things you want to check permissions on, maybe on a wiki page
> somewhere, and indicate in there which ones are done and which ones
> are not done, and what additional information you think is needed in
> each case, and flag any MAC/DAC discrepancies that you are concerned
> about.  I think that might help us reach agreement on the best way
> forward.  Also, then, as we get things committed, we can track
> progress versus that roadmap.
>
I tried to summarize permission checks of DAC/MAC on several object classes
that are allowed to assign security label right now.
http://wiki.postgresql.org/index.php?title=SEPostgreSQL/Permissions

In most of checks, required contextual information by SELinux are commonly
used to DAC also, as listed.

On the creation of relations, SELinux requires relkind and TupleDesc to
identify relation type and columns. Unlike a flag of select-into, I'm not sure
whether it is a model specific and hard to manage without knowledge about
sepgsql internal.

In some cases, DAC uses superuser privilege as a substitute for individual
permission checks, such as DefineType().
It seems to me its original implementation checked CREATE permission of
the namespace and ownership of the functions that implements type input,
output or others, then, we commented out these code because superuser
is obviously allowed these checks.
However, MAC does not have concept of superuser, so, SELinux wants to
check db_procedure:{install} for each functions, thus, it requires oid of
the functions to be used for the new type.
Of course, we can see here is no difference between DAC and MAC, if we
consider DAC implicitly allows these checks by superuser().

I think it is a good start to implement first ddl permissions on creation of
the seven object classes as listed; also to proof the concept; 1) we put
permission checks around existing DAC checks, 2) we deliver contextual
data (basically) used in existing DAC also.

I guess DROP or some of ALTER code reworking should be done prior to
deploy object_access_hook around their permission checks, to minimize
maintain efforts.

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