Re: 8.4 release planning - Mailing list pgsql-hackers

From Joshua Brindle
Subject Re: 8.4 release planning
Date
Msg-id 497F789F.8000809@manicmethod.com
Whole thread Raw
In response to Re: 8.4 release planning  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> Personally, I think it'd be terrible to implement the suggestion that
>> started this sub-thread since it breaks with what is currently done
>> elsewhere and what the users of this feature would expect.
> 
> Upthread we were being told that this patch breaks new ground and will
> offer capability available nowhere else.  Now I'm hearing that it's just
> a "me too" patch to catch up with capability already available from N
> commercial vendors.  Which is it?
> 

It is like the difference between Trusted Solaris (really all the old trusted 
OS's) and SELinux. They both implement mandatory access control and both 
implement Bell and LaPadula as needed by the government/military but SELinux, 
via type enforcement, goes further to provide a completely flexible mandatory 
access control system.

SELinux is useful to meet all sorts of security goals, from system and 
application integrity to data pipelining and confidentiality. The SELinux 
community believes this sort of access control is important to not only the 
military but commercial and even small scale systems.

Further, because sepostgresql integrates well with SELinux the same system wide 
access controls flow seamlessly into the database. Are you able to access secret 
data on the filesystem? If so you'll be able to access secret data in the 
database. Are you able to update accounting information in the filesystem? Then 
you'll be able to update accounting information in the database.

This also integrates with KaiGai's other work to SELinux-ize apache so that an 
apache server can run a user script from a users home directory and a type 
transition occurs to run the script in the appropriate domain for that user, 
then when that script accesses the database they'll have only the access that 
users script should have.

This kind of end-to-end integration with mandatory access control is certainly 
ground breaking and isn't just the same ol' same ol' that other database vendors 
are doing (and have been doing for quite some time).


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_upgrade project status
Next
From: Stephen Frost
Date:
Subject: Re: 8.4 release planning