Re: SE-PostgreSQL Specifications

On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
> Robert Haas wrote:
> >Sam Mason wrote:
> >>The traditional approach would be to maintain multiple physically
> >>separate databases; in this setup it's obvious that when you perform a
> >>backup of one of these databases you're only seeing a subset of "all of
> >>the objects". Isn't SE-PG just allowing you to do this within a single
> >>PG database?
> >
> >Partly. There's also a concept called "read down", which is
> >important. It allows you to have, say, secret and classified data in
> >the same database, and let the secret users see both types but the
> >classified users see only the classified stuff, not the secret stuff.
> >If you want to store intelligence data about the war in Iraq and
> >intelligence data about the war in Afghanistan, it might not be too
> >bad to store them in separate databases, though storing them in the
> >same database might also make things simpler for users who have access
> >to both sets of data. But if you have higher and lower
> >classifications of data it's pretty handy (AIUI) to be able to let the
> >higher-secrecy users read the lower-secrecy data - if you used
> >separate databases to simulate read-down, you'd have to replicate data
> >between them, and also have some manual mechanism for tracking which
> >level of secrecy applied to which to which data.
>
> It seems a correct description.
>
> In addition, we also need to prevent that higher-secrecy users writes
> anything to the lower-secrect objects to prevent information leaks.

OK, so to bulk out this physical analogy we'd have two physical servers
one that stores "higher-secrecy" stuff and one for "lower-secrecy"
stuff. Users with higher clearance are able to read/write the higher
secrecy database but only read the lower secrecy database. Users with
lower clearance can only read/write the lower secrecy database, ideally
they aren't even aware of the existence of the higher secrecy one.

> In some cases, the clearance of infoamtion may be changed. We often
> have dome more complex requirements also.

OK, so there is some other trusted entity that has unfettered access to
both databases and its job is to manage these requirements.

> Thus, it is necessary a capability to store and manage data objects
> with different security labeles in a single database instance here.
> (If we don't want to use commercial solutions instead.)

SE-PG is about doing the above in one database and allowing more
rigorous checks to be done?

--
Sam http://samason.me.uk/