Simon Riggs wrote:
> On Fri, 2008-11-07 at 16:52 -0500, Bruce Momjian wrote:
>> Simon Riggs wrote:
>>>>> 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.
>> Simon, would you read the chapter on "covert channels"? You might
>> understand it better than I do and it might give you some ideas:
>>
>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950
>
> It's probably easier just to say "here is the specification we;re
> working to implement".
This document gives us some of hints to be considered when we
apply mandatory access control facilities on database systems.
However, it is not a specification of SE-PostgreSQL.
The series of documents assumes traditional multi-level-security
system, so it does not care about flexible policy, type-enforcement
rules and collaborating with operating system.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>