Re: security label support, revised

2010/9/13 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> Robert, although you suggested that only one ESP module shall be
> invoked on relabeling an object before, and I agreed this design
> at that time, but I noticed that we cannot implement the following
> behavior correctly.
>
> SELinux defines these permissions corresponding to table relabeling.
> - db_table:{setattr}
>  It is necessary to change *any* properties of the table.
>  Security label is one of properties of the table, so, needs to be
>  checked on relabeling, not only ALTER TABLE and so on.
> - db_table:{relabelfrom relabelto}
>  It is neccesary to change label of the table.
>  User must have {relabelfrom} permission on the older security label,
>  and {relabelto} permission on the new security label.
>
> If and when multiple ESP modules are installed, we need to consider
> the way to handle SECURITY LABEL statement for other modules.
> When user tries to relabel security label of a table managed by
> something except for selinux, it is not relevant to {relabelfrom
> relabelto} permission in selinux, but we want to check {setattr}
> permission on the operation, because it is a property of the table,
> although not a security label in selinux.
>
> In the current patch, the core PG (ExecSecurityLabel()) invokes only
> one hook that matches with the given "FOR <esp>" option.
> However, I reconsidered this hook should be simply invoked like other
> hooks. Then, the ESP module decides whether ignores or handles the
> invocation, and also decides to call secondary hook when multiple
> modules are loaded. If so, selinux module can check {setattr} and
> also calls secondary modules.
>
> In the previous discussion, I missed the possibility of the case
> when we want to check relabeling a security label managed by other
> ESP. But it might be also necessary to call all the modules which
> want to get control on SECURITY LABEL statement, apart from whether
> it manages the supplied security label, or not.

Maybe. The whole point of MAC is that the security policy itself is
capable of enforcing all of the necessary protections. It shouldn't
be necessary for it to control what DAC or other MAC providers do,
should it? At any rate, they'll probably treat it quite a bit
differently than a change of their own label. I think it might be
cleaner to fold that in under some of the DDL permissions checking and
refactoring which we know still needs to be done, rather than cramming
it in here. Note that presumably COMMENT ON would need similar
treatment, and there may be other things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company