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.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
