Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] SE-PgSQL/tiny rev.2193

From: Joshua Brindle <method(at)manicmethod(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193
Date: 2009-07-21 14:20:09
Message-ID: 4A65CE99.4000309@manicmethod.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark wrote:
> On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle<method(at)manicmethod(dot)com>  wrote:
>> I am capable of speaking for Tresys in this matter. We are very interested
>> in this work and our US DoD customers need the capabilities that this
>> project adds (assuming row level access controls are a possibility).
>
>
> I'm kind of curious about how these features get used. What specific
> problems do they solve?
>

Backing up from KaiGai's description a bit, basically what this is needed for is 
storing multilevel data in a single db instance.

For example, you have people logging in from different classifications (unclass, 
secret, top secret, etc) and the data they put in is marked (labeled) with their 
classification label.

Then for queries the policy is used to determine who can see what. An unclass 
user will only be able to see unclassified data. A top secret user, however, can 
see all the data from top secret, secret and unclassified. This is why the view 
model doesn't work, we need 'read down' support. This also implies that key 
constraints are held between data of differing levels. This has some information 
leak side effects (eg., if an unclass user inserts data then waits 5 minutes and 
inserts again and sees the key incremented greatly he knows lots of classified 
data is going into the database) but this is a small information leak compared 
to the gain in functionality of a read-down system.

The alternative to having this built in to the system is having many instances 
of postgres (or something else) running and having to query the right one to get 
the data (or all of them) and manually collating and associating rows. Very 
non-ideal. I have seen this method used en luau of having a multilevel database.

Another scenerio is that all the data being put in is of some classification 
(eg., radar data coming from a piece of equipment is all marked secret) but some 
of the data is top secret. For example a column that has precise coordinates of 
enemy soldiers is higher classification than the rest of the data. A secret user 
may be allowed to query the data with some 'fuzz', through a trusted stored 
procedure. So the secret user wouldn't have direct access to the coordinates but 
could call a stored procedure to get the information with precision removed.

This is why column level, row level and stored procedure access controls are all 
really required for the applications we are looking at.

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-07-21 14:36:20
Subject: Re: Sampling profiler updated
Previous:From: Tom LaneDate: 2009-07-21 14:06:57
Subject: Re: [PATCH] user mapping extension to pg_ident.conf

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group