Greg Stark wrote:
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle<met...@manicmethod.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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
