(2010/09/13 20:46), Robert Haas wrote:
2010/9/13 KaiGai Kohei<kai...@ak.jp.nec.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?
Yes, what we should do here is that DAC and any MACs make their own
decision individually, then PG eventually prevents user's request if
one of them denied at least.
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.
Yes, if and when MAC-X and MAC-Y are installed, it is significant event
for MAC-X to change X's label, so MAC-X may need to check special
permissions. But it is a common event for MAC-Y and DAC, so they checks
an appropriate permission to change one of the properties. Hoever, it
does not mean we should not give any chance MAC-Y and DAC to check something.
I'll revise my patch within a couple of days.
Thanks,
Note that presumably COMMENT ON would need similar
treatment, and there may be other things.
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
