Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE - Mailing list pgsql-hackers

KaiGai Kohei wrote:
> Robert Haas wrote:
>> On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
>> <kleptog@svana.org> wrote:
>>> On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote:
>>>> So in this situation -- I suspect, if any SELinux people want to pipe
>>>> up to tell me whether I'm on the right track -- the idea is that you
>>>> should be able to examine a user superficially and know for certain
>>>> whether he has the ability to lock a record or whether that privilege
>>>> has been denied him. It shouldn't be possible for him to gain the
>>>> privilege by going through a view or trigger which runs as another
>>>> user.
>>> My (admittedly superficial) research into the topic suggests to me that
>>> it's because SELinux is entirely into protecting the data. It doesn't
>>> really care whether you're accessing it via a view or function or what.
>>> If you don't have permissions you can't get it and no-one within
>>> postgresql can grant you access either (that's why it's MAC).
>>>
>>> The way I understood the specific problem here is that SELECT FOR
>>> UPDATE doesn't semantically change any data so you don't really need
>>> UPDATE permissions to do it. That's just an artifact of the Postgres
>>> implementation.
>>>
>>>> If on the other hand I'm wrong and this isn't a fundamental feature
>>>> but just an implementation question then I think the right solution is
>>>> to fix the problems that make it hard to implement the Postgres
>>>> security model in SELinux. The consensus earlier was that the first
>>>> version of the patch to land would just be a minimal patch which
>>>> implements the existing security model using SELinux without making
>>>> any changes to the model. Playing around with new privileges and how
>>>> we distinguish referential integrity checks wouldn't be part of that.
>>> ISTM that limiting the patch to doing what can already be done with
>>> standard postgresql is silly. SE-Postgres is not trying to supplant the
>>> Pg model, it's trying to do things that the Pg model can't do. Namely,
>>> label stuff secret and be sure no-one without clearence can read it,
>>> even if someone makes a setuid function for it.
>> Not really, because SE-PostgreSQL introduces its own analogue of
>> setuid/security definer, which happens to be called "trusted
>> procedure", and you can do the same darn thing.
>>
>> The issue at hand is foreign key constraints.  Standard PostgreSQL
>> checks those constraints as the table owner using the table owner's
>> credentials.  The question is whether there's some reason why
>> SE-PostgreSQL shouldn't do the same.
> 
> It is an idea to be worth considering, I think.

Robert, currently I could not find semantics breaks in your suggestion.
I plan to update SE- implementation to skip checks during foreign-key
constraints and add a new SE- permission: "reference" which allows
to set up fereign-keys.

Thanks,

> The current foreign-key implementation internally invokes secondary
> queries to check whether the given tuples satisfies the constraints,
> or not. SE-PostgreSQL checks any given queries and permissions on
> the required database objects, so the secondary queries are also
> checked.
> 
> However, the way to achive foreign-key feature is purely depending
> on the implementation of DBMS, so we might be able to consider it
> as a part of system internal stuff.
> For example, if PostgreSQL implemented the foreign-key feature using
> hard-wired functions, we don't need to apply checks here because of
> it is not a query.
> One possible compromise is to skip SE- checks during foreign-key
> checks. I'll consider the idea a bit more.
> 
> BTW, as we have discussed many times, SE-PostgreSQL does not intend
> to prevent unpriv users to infer existence of invisible tuples.
> So, this design changes will not be a headach for me.
> 
> Thanks,
> --
> OSS Platform Development Division, NEC
> KaiGai Kohei <kaigai@ak.jp.nec.com>

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>