Message-ID: <49EE5E34.1010200@ak.jp.nec.com>
Date: Wed, 22 Apr 2009 09:00:52 +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>
	<49ED12B2.5030408@ak.jp.nec.com>
In-Reply-To: <49ED12B2.5030408@ak.jp.nec.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

KaiGai Kohei wrote:
> 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.

Robert, currently I could not find semantics breaks in your suggestion.
I plan to update SE- implementation to skip checks during foreign-key
constraints and add a new SE- permission: "reference" which allows
to set up fereign-keys.

Thanks,

> 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>

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>