Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

Robert Haas wrote:
> On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
> <kleptog(at)svana(dot)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.

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(at)ak(dot)jp(dot)nec(dot)com>