Re: SE-PostgreSQL Specifications

On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason<sam(at)samason(dot)me(dot)uk> wrote:
> On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote:
>> There had better still be superusers.  Or do you want the correctness
>> of your backups to depend on whether your SELinux policy is correct?
>
> 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.

> 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. 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. And while I believe
SE-Linux/SE-PostgreSQL would allow you to configure such a system, you
might want to think carefully before you decide to do so, and the
system certainly shouldn't (and can't) force you to set it up that
way.

>> The first time somebody loses critical data because SELinux suppressed
>> it from their pg_dump output, they're going to be on the warpath.
>
> That should be solved by different methods; as "A.M" said pg_dump can
> complain if it doesn't see everything it expected to (which should
> handle the naive user case) and backdoors can be put in the scheme
> that will (by default?) initially allow a "backup" subject unfettered
> read-only access to each object.  I'm expecting that this access can be
> revoked as needed from sensitive tables.

If pg_dump can tell that there is information missing, the system
hasn't done a very good job of hiding its existence, which is surely
the whole point here. Even if SE-PostgreSQL isn't explicitly worried
about eliminating covert channels, it seems like a terrible idea to
design a database backup tool that operates by exploiting ones we
haven't chosen to eliminate.

...Robert