Re: SE-PostgreSQL Specifications

On Sat, Jul 25, 2009 at 7:49 PM, Sam Mason<sam@samason.me.uk> wrote:
> On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
>> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason<sam@samason.me.uk> wrote:
>> > I thought the whole point of MAC was that superusers don't exist any
>> > more--at least not with the power they currently do.
>>
>> It's been billed that way, but it's not really accurate.  A more
>> accurate statement would be that it's possible to create a system in
>> which there is no unconfined role.
>
> Yes, that sounds more precise!
>
> I'm still unsure of terminology; what's a "unconfined role"?  I guess
> the layman's description is similar to a "superuser", but I'm sure
> there's a more refined definition somewhere.  Hum, I've just found
> Fedora's guide, is the following considered a reasonable picture:
>
>  http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html
>
>> > Organizations may
>> > well not trust specific parts of their database to certain types of
>> > backups, SE-PG should allow this to be controlled somewhat.
>>
>> I imagine it would be possible to run pg_dump on a database where you
>> couldn't see all of the objects, and get a dump of just those, but
>> that's only tangentially related to whether such things as superusers
>> exist.
>
> I'm not sure what point you're trying to make; in my understanding
> superusers can see and do anything--hence they can make a backup.
>
>> If superusers DON'T exist, that would be making the opposite
>> statement, namely, that there isn't ANY WAY to get a backup that you
>> can be sure DOES contain all of the objects.
>
> 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.

All of the foregoing is my very layman's understanding of this, so
take it with a grain of salt.

...Robert