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

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.

...Robert