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 23:29:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Greg Stark wrote:
> On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle<method(at)manicmethod(dot)com>  wrote:
>> You also snipped the other scenario I had where row based access control
>> isn't required but column level and stored procedure level are.
> Well we already have column level and stored procedure privileges.
>> 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.
> Sure, and people do this every day already with postgres roles and privileges.
>> 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.
> Well the question is: Is the important feature of SEPostgres the
> unification of the privilege model with every other piece of the
> system in the SELinux policy? Or is that not the main thing and only
> the row-level access security is interesting. None of the use cases
> seem to put any emphasis on the unification of the security policy.

I don't understand how you came to this conclusion. Quoting from my 
prior email:

""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. ""

In this case the selinux context (which specifies their MLS level) says 
the user is running at unclass and there should be no possible 
credentials or role or anything that gives him access to data above 
unclass in the database. This _is_ a unification of the policy because 
whether the unclass user is accessing files or rows in a mixed-level 
database or entire databases that are classified as such the SELinux 
policy is governing that.

Its the same with selinux aware X. If a user is running 2 database 
clients, one at unclass and one at secret then each application would 
how the appropriate results. The policy also disallows that user from 
copying from the secret database client into the unclass client (in this 
case there are SELinux rules enforcing behavior of X apps, of the 
database clients and of the filesystem), unified indeed.

In response to

pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2009-07-21 23:43:54
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193
Previous:From: KaiGai KoheiDate: 2009-07-21 23:27:56
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193

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