Re: security label support, revised

(2010/09/13 20:46), Robert Haas wrote:
> 2010/9/13 KaiGai Kohei<kaigai@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 <kaigai@kaigai.gr.jp>