Message-ID: <49ED12B2.5030408@ak.jp.nec.com>
Date: Tue, 21 Apr 2009 09:26:26 +0900
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Robert Haas <robertmhaas@gmail.com>
CC: Martijn van Oosterhout <kleptog@svana.org>,
	Greg Stark <stark@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	KaiGai Kohei <kaigai@kaigai.gr.jp>, pgsql-hackers@postgresql.org
Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE
References: <49E9D5B6.9050406@enterprisedb.com>	
	<49EAD5A6.4010601@enterprisedb.com>
	<49EADF16.3050400@kaigai.gr.jp>	 <12899.1240152674@sss.pgh.pa.us>
	<49EBC588.4090807@ak.jp.nec.com>	
	<49EC0B94.6070107@enterprisedb.com>
	<49EC198F.6090604@ak.jp.nec.com>	 <5233.1240236841@sss.pgh.pa.us>	
	<4136ffa0904200748k67a6058bue08c233a745317bc@mail.gmail.com>	
	<20090420164800.GC29747@calyx.svana.org>
	<603c8f070904201137p72d805ai6b75c70ee8c31bfd@mail.gmail.com>
In-Reply-To: <603c8f070904201137p72d805ai6b75c70ee8c31bfd@mail.gmail.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

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.

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>