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 15:24:55
Message-ID: 4A65DDC7.7040903@manicmethod.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark wrote:
> On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindle<method(at)manicmethod(dot)com>  wrote:
>> 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.
>>
>
>
> I'm beginning to wonder if we haven't gone about this all wrong. Every
> time someone asks my question about use cases the only answers that
> come back are about row-level security. Perhaps that's the only case
> that really matters here.
>
> If we provide a way to control access to database objects through
> SELinux policies -- ie, one which is functionally equivalent to what
> we have today but just allows administrators to control it in the same
> place they control other SELinux system privileges, is that useful? Is
> that something SE administrators want? Or are they happy to use
> Postgres roles and grants and just want the finer row-level data
> access controls?
>

No, for multiple reasons. First a single person (role) could be logging in at 
different levels (eg., running the same application as the same linux user with 
the same credentials) and would need to see different things from the database. 
The SELinux contexts would provide the differentiation in this case and the 
SELinux policy would enforce the multilevel policy.

I also don't think your roles and grants could enforce a multilevel policy but 
that is something I'd have to look into deeper to know for sure. Also the 
objects need to be labeled based on how they were inserted, and 're-grading' 
applications need to be able to relabel them. You still need the 'read-down' 
behavior I talked about above.

You also snipped the other scenario I had where row based access control isn't 
required but column level and stored procedure level are. I understand you 
already have column level access controls but it still goes back to how the user 
is accessing the data, as a top secret user who can read the column with full 
precision or as a secret user with precision removed via a trusted stored 
procedure. The SELinux policy would have to give the stored procedure the 
ability to read the column and trust it to remove the necessary amount of precision.

In response to

Responses

pgsql-hackers by date

Next:From: Lars KanisDate: 2009-07-21 15:35:08
Subject: Re: [PATCH] user mapping extension to pg_ident.conf
Previous:From: Robert HaasDate: 2009-07-21 15:17:29
Subject: Re: Sampling profiler updated

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