Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date: 2008-09-24 15:14:53
Message-ID: 200809241514.m8OFEro17783@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

KaiGai Kohei wrote:
> Tom Lane wrote:
> > Josh Berkus <josh(at)agliodbs(dot)com> writes:
> >> Multilevel frameworks have concepts of data hiding and data substitution
> >> based on labels. That is, if a user doesn't have permissions on data,
> >> he's not merely supposed to be denied access to it, he's not even supposed
> >> to know that the data exists. In extreme cases (think military / CIA use)
> >> data at a lower security level should be substitited for the higher
> >> security level data which the user isn't allowed. Silently.
> >
> > Yeah, that's what I keep hearing that the spooks think they want.
> > I can't imagine how it would play nice with SQL-standard integrity
> > constraints. Data that apparently violates a foreign-key constraint,
> > for example, would give someone a pretty good clue that there's
> > something there he's not being allowed to see.
>
> Please note that SE-PostgreSQL does not adopt following technology
> because of its complexity. When user tries to update a PK refered by
> invisible FK, it generate an error. Thus, it is theoretically possible
> to estimate the invisible PKs by attacks with repeating.

I assume if you use only non-natural keys (use sequence numbers, not
codes like PHL or USA), there is no problem in finding the missing keys
by repeated testing.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-09-24 15:14:59 Re: FSM, now without WAL-logging
Previous Message Peter Eisentraut 2008-09-24 15:13:59 Default SHMMAX on Linux