Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 5022F633488 for ; Mon, 20 Apr 2009 20:56:29 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 84921-06 for ; Mon, 20 Apr 2009 20:56:15 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by mail.postgresql.org (Postfix) with ESMTP id 2BC0C63255A for ; Mon, 20 Apr 2009 20:56:21 -0300 (ADT) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id n3KNuDGc002026; Tue, 21 Apr 2009 08:56:13 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id n3KNuDh00238; Tue, 21 Apr 2009 08:56:13 +0900 (JST) Received: from mailsv.linux.bs1.fc.nec.co.jp (mailsv.linux.bs1.fc.nec.co.jp [10.34.125.2]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id n3KNuC5U018460; Tue, 21 Apr 2009 08:56:12 +0900 (JST) Received: from [10.19.71.82] (unknown [10.19.71.82]) by mailsv.linux.bs1.fc.nec.co.jp (Postfix) with ESMTP id 6C069E482C3; Tue, 21 Apr 2009 08:56:12 +0900 (JST) Message-ID: <49ED0B9C.10109@ak.jp.nec.com> Date: Tue, 21 Apr 2009 08:56:12 +0900 From: KaiGai Kohei User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gregory Stark CC: Tom Lane , Heikki Linnakangas , KaiGai Kohei , pgsql-hackers@postgresql.org Subject: Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE References: <49E809F6.8070008@ak.jp.nec.com> <49E9D5B6.9050406@enterprisedb.com> <49EA7E4D.6060109@kaigai.gr.jp> <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> <6167.1240239593@sss.pgh.pa.us> <87myab49ri.fsf@oxford.xeocode.com> In-Reply-To: <87myab49ri.fsf@oxford.xeocode.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.094 tagged_above=0 required=5 tests=AWL=0.094 X-Spam-Level: X-Archive-Number: 200904/1056 X-Sequence-Number: 137159 Gregory Stark wrote: > Tom Lane writes: > >> Greg Stark writes: >>> 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. >> Well, if so, the idea is a miserable failure. SELinux has just as many >> setuid programs as any other Unix, and absolutely zero hope of removing >> them. I am not going to take the idea of "remove setuid" seriously when >> they haven't been able to accomplish it anywhere else. > > But can you remove privileges from users to make these programs ineffective? > So even if you obtain root privileges you're missing the SE privilege which > the program expects to use? It is also too radical goal for SELinux. :-) SELinux intends to prevent "unexpected" privilege escalation, but it does not mean to eliminate setuids. The "unexpected" means the actions are not explicitly allowed in the security policy. The SELinux privileges mechanism works orthogonally with DAC mechanism. If a user runs a root-setuid program, he can get full-controllable privileges in the DAC rules, but SELinux checks his privileges from different aspect to mask unallowed privilges due to the MAC rules. Thus, SELinux makes its decision based on only security contexts, independent from user identifier and other factors. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei