Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VtChJ-000888-Su for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Dec 2013 08:41:42 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VtChJ-0003h3-Bm for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Dec 2013 08:41:41 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VtChI-0003gt-0W for pgsql-hackers@postgresql.org; Wed, 18 Dec 2013 08:41:40 +0000 Received: from mail-we0-x22b.google.com ([2a00:1450:400c:c03::22b]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VtChE-00038L-4l for pgsql-hackers@postgresql.org; Wed, 18 Dec 2013 08:41:39 +0000 Received: by mail-we0-f171.google.com with SMTP id q58so7232938wes.30 for ; Wed, 18 Dec 2013 00:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=X8eS5rROHJU6g/vujRtkj8qshC/ByhOnUJ5Soadukn8=; b=fb4tVFolF523RarZXq7AWqtoOfn7O4sDqAs6MaTsgJ7yrpdfvdCDG6tHTiaCJZ0NdU UpIfauuPAyK3X6jsVj5BvvPM2n5oKpV8TV4674CG8WVlnAfWMz1LQndkAMJndBXhaSuU /SwaP2pBDjGaHEGrJ8F91tBRck1TIdoM+mURqKKJb5fEcOW0frmuIBNibIiYmJ3CyLE+ Szjv0U0amJbnufG2kIsb3aiy/TPEUqmqUZITO0Un7LX15P+uFho6ksKzIzZEoSmkAxG5 Mysfws99U38gGy7CEsZxcJRwCzUhY5MlUWpoAHb9bw+0aV6x9cyu/2OibI8jbWQrX/XW APhA== X-Received: by 10.180.37.69 with SMTP id w5mr6880865wij.53.1387356095211; Wed, 18 Dec 2013 00:41:35 -0800 (PST) Received: from [192.168.73.37] (5357DA75.cm-6-8d.dynamic.ziggo.nl. [83.87.218.117]) by mx.google.com with ESMTPSA id w20sm2077150wia.5.2013.12.18.00.41.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Dec 2013 00:41:34 -0800 (PST) Message-ID: <52B15FD1.9020407@gmail.com> Date: Wed, 18 Dec 2013 09:41:53 +0100 From: Yeb Havinga User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Craig Ringer CC: PostgreSQL-development Subject: Re: [v9.4] row level security References: <5220D832.7090104@agliodbs.com> <20130830192729.GO2706@tamriel.snowman.net> <16798.1377891794@sss.pgh.pa.us> <1398.1378305956@sss.pgh.pa.us> <1543.1378306249@sss.pgh.pa.us> <2620.1378308159@sss.pgh.pa.us> <52775604.9090306@2ndquadrant.com> <11101.1383575839@sss.pgh.pa.us> <52784DF9.9040205@2ndquadrant.com> <5279E3CA.7050400@2ndquadrant.com> <527C478D.4070901@2ndquadrant.com> <52ABCF6C.4010409@gmail.com> <52ABE150.6050201@2ndquadrant.com> In-Reply-To: <52ABE150.6050201@2ndquadrant.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2013-12-14 05:40, Craig Ringer wrote: > I find the heirachical and non-heirachical label security model used in > Teradata to be extremely interesting and worthy of study. > > The concept is that there are heirachical label policies (think > "classified", "unclassified", etc) or non-heirachical (mutually > exclusive labels). A user can see a row if they have all the policies > used in a table, and each of the user's policy values is sufficient to > see the row. For non-heiracical policies that means the user and row > must have at least one label in common; for heiracical policies it means > the user label must be greater than or equal to the row label. > > That model lets you quite flexibly and easily build complex security > models. It'd work well with PostgreSQL, too: We could implement > something like non-heirachical policies using a system varbit column > that's added whenever a non-heirachical policy gets added to a table, > and simply AND it with the varbit on the user's policy to see if they > can access the row. Or use a compact fixed-width bitfield. Heirachical > policies would use a 1 or 2 byte int system column to store the label. Is is necessary to fix the attribute type of the security label? The label model described above seems to restrictive to support e.g. the labels described on p18 of the 'healthcare classification system' (HCS) (http://www.hl7.org/documentcenter/public/wg/secure/3.%20HCS%20Guide%20Final%202013%200322%20JMD.pdf). The HCS security label is based on the NIST's FIPS188 standard / http://www.itl.nist.gov/fipspubs/fip188.htm regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers