Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

On Mon, Apr 20, 2009 at 3:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It seems to me a quite ad-hoc idea.
>
> That's rather a silly charge to be leveling when your own proposal is
> such a horrid kluge as this one.  As near as I can tell, you intend
> that SELinux will be unable to prohibit SELECT FOR UPDATE because it
> cannot tell the difference between that and a foreign key reference.
> If that isn't a hack, I don't know what is.

I think we're talking at cross purposes here. I think Kai Gai's
descriptions make sense if you start with a different set of
assumptions. The idea behind SELinux is that each individual object is
access controlled and each user has credentials which grant access to
specific operations on specific objects. As I understand it part of
the goal is to eliminate situations where "setuid" or other forms of
privilege escalation is required.

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.

If that's right then the previous suggestion that we take only the
part of SELinux which maps to the existing POstgres model really falls
down. SEPostgres won't map to the Postgres model just as SELinux
doesn't map directly to the traditional Unix security model. It'll be
a whole new security model which may be internally consistent but
won't make sense to think about together with the Postgres model. That
would be a hard sell because as demonstrated in this thread, we don't
really understand the SE security model and it would probably be quite
invasive to support.

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.

--
greg