Re: Recent status of SE-PostgreSQL

["cto@itechfrontiers.com" <cto@itechfrontiers.com>]

Joshua,

 > Postgres is inherently trusted with it's own objects, the kernel 
cannot  mitigate that.

Aha that's the point, daemons cannot be trusted, in case of DBMS it must 
be isolated anyway, (System Security wise)

So the goal is to create Trusted DBMS, that's another topic and 
PostgreSQl has a long way to reach that point

I wrote to be PRACTICAL, and asked what is its practical question, to me 
I got the answer, it is a milestone of the roadmap to a Trusted DBMS 
using PostgreSQL

but being imaginary, in terms of MLS, WHY on EARTH you have to combine 
classified and public data on the same Database?  this is in contrary to 
all security measures regarding MLS design !!!

Nobody says that to dismiss Database Security model,

And since all codes must be audited in such cases, isolation and 
utilization of gateways (middleware) on completely separate clusters are 
usually utilized , despite to the fact that classified data requires 
different level of encryption, so different systems need to handle that,

Best Regards,

Patrick K.


 > Quite the contrary. How do you suppose you will protect access to
 > objects that are opaque to the kernel without implementing a security
 > model in the daemon?

Who has said not to have an access model in DBMS? I said it is not 
necessary to rely on external sources,  internal modeling is much more 
concise, less generic and stripped down to bare-bone requirements thus 
keeping up performance

Patrick K.



On 12/9/2010 11:10 AM, Joshua Brindle wrote:
> cto@itechfrontiers.com wrote:
>> KaiGai,
>>
>> Thanks for explanation, I see, but it seems I need to explain my points:
>> (We are talking about designing and implementing secure and robust
>> systems) and
>> I had objections based on Practical utilization,
>>
>> 1) From System Wide Perspective, PostgreSQL is another daemon and
>> should not be
>> trusted and thus we give it unprivileged user and control its entire
>> daemon with
>> MAC and give Postgres its own little island to rule (I'm sure you
>> aware of this)
>
> Postgres is inherently trusted with it's own objects, the kernel cannot
> mitigate that. The idea is to use extend access controls deeper into
> objects that the kernel cannot itself control access to. The Postgres
> process and database files will be protected by SELinux using kernel
> access controls and SELinux policy is extended into Postgres.
>
> As an example, lets talk about MLS. If a secret user cannot access top
> secret data on the filesystem, but can in the database your system is
> not capable of implementing the security model you've deemed necessary.
>
> There are several current and historic implementations of database
> systems that implement an MLS policy. Where they fall short is
> integration with the rest of the security policy.
>
> Because SELinux provides ways to 1) get the context of a process on the
> other end of a socket from the kernel, 2) use that context to get access
> control decisions from the in-kernel SELinux policy and 3) implement a
> consistent policy across multiple object managers we are able to build a
> comprehensive and deep security policy that cannot be bypassed (assuming
> your policy does not allow bypass).
>
> Using labeled networking it gets even better. Someone sitting on a
> desktop running a database client labeled someuser:nurse_r:nurse_t can
> have precise access granted to the patient tables via labeling, specific
> columns can be removed from their view. Regardless of the credentials
> used to log in to the DBMS the MAC policy takes priority.
>
>>
>> 2) You are going to put the same tool, SELinux to rule that little
>> island of
>> PostgreSQL, for internal objectives, access control and virtual users:
>>
>> In my Mumble Opinion, The are objections IN PRACTICAL usage here:
>>
>>
>> 2-1) IMHO, Using the same SELinux for creating control on internal daemon
>> architecture (access) is in contrary to "Defense in Depth doctrine"
>> (there
>> supposed to be different layers of security and defense, and not to
>> rely on a
>> single point of failure which here is actually policy making and
>> administration
>> of those policies)
>>
>
> Quite the contrary. How do you suppose you will protect access to
> objects that are opaque to the kernel without implementing a security
> model in the daemon?
>
>> 2-2) IMHO, down from hierarchy of system wide (kernel), MAC/RBAC
>> INTERNALLY
>> within daemons (programs) should be MAC/RBAC by design not as an
>> add-on of
>> external source , A) because of performance implications B) they are
>> not on the
>> same level of trust in contrast to security, and Security adminis
>> cannot deal
>> with internal structures and objectives of applications in practical
>> daily
>> usages this is why they are isolated, it is up to the developers to
>> provide and
>> thus why an external source which is resource intensive should be
>> used, Virtual
>> user privileges within database are not mapped directly to system
>> resources,
>>
>>
>> 2-3) Adding SE-PostgreSQL does not bring the daemon at the same level
>> of trust
>> and it should be sandboxed or isolated anyway, and of course internal
>> users of a
>> DBMS should not be mapped from system users, this is why VIRTUAL users
>> are used
>> within DBMS , (same defense doctrine)
>> so why should use an external source for MAC/RBAC, when it should be
>> MAC by
>> design not as an add-on
>>
>>
>> 2-4) In secure deployment a MIDDLEWARE is placed between web and a
>> totally
>> isolated DBMS for the purpose of Content filtration and analysis (not
>> to trust
>> WEB applications or its programmers) and for the purpose of load
>> balancing, as
>> well as security isolation, (AT LEAST WE DO SO)
>> for trusted systems, it is possible to put a single database within a
>> single
>> instance of Postgresql and do not share it with other databases,
>> since postgresql is process based it does not introduces much more
>> resource
>> consumption (as it only needs one additional master process per
>> instance of
>> PostgreSQL)
>>
>
> Trusting the middleware is placing trust in the wrong layer. You must
> implement access controls in the object owner to have any assurance that
> it is non-bypassable.
>
> If you can find it, dig up the papers written for the Integrity Lock
> DBMS. They are a bit dated (we are talking 80's). Also Security in
> Computing by Pfleeger has a chapter on database security.
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
> with
> the words "unsubscribe selinux" without quotes as the message.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.