Simon Riggs wrote:
> On Fri, 2008-11-07 at 15:12 -0500, Robert Haas wrote:
>>> Foreign Key deletions could be handled correctly if you treat them as
>>> updates. If we have the following example
>>>
>>> TableA
>>> security_context=y value=2 fk=1
>>>
>>> TableB
>>> security_context=x value=1
>>>
>>> TableA refers to TableB. Context x cannot see context y.
>>>
>>> So if somebody with context x tries to delete value1 from TableB, they
>>> will be refused because of a row they cannot see. In this case the
>>> correct action is to update the tuple in TableB so it now has a
>>> security_context = y. The user with x cannot see it and can be persuaded
>>> he deleted it, while the user with y can still see it.
>> It seems odd for a low-privilege user to be able to elevate the
>> privilege of a tuple above their own privilege level. I also don't
>> believe that the privilege level is a total order, which might make
>> this something of a sticky wicket. But those are just my thoughts as
>> a non-guru.
>
> The low-privilege user isn't elevating the label. If the tuple was
> visible by multiple labels it was already elevated. All I am suggesting
> is the system remove the one it can see, leaving the other ones intact.
> This makes the row appear to be deleted by the lower privileged user,
> whereas in fact it was merely updated. There need not be any ordering to
> the labels for this scheme to work.
SELinux does not allow a object has two or more labels.
You implicitly assume the security mechanism allows users to access
when one of the labels allows it, but there is no consensus.
At the past, an idea of multiple labels is discussed in SELinux community,
but it was finally dropped because we cannot define the behavior when the
security policy makes different decision for two different labels.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>