Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)

Simon Riggs wrote:
> Some initial thoughts based upon reading the Wiki. I've not been
> involved in things up to now, so if this dredges up old discussions,
> well, these are my thoughts.
> 
> I want SEPostgreSQL, but I'd like it to work without needing to be a
> compile time option so people can just use it as/when needed. Plus we
> don't want to support what would be/is essentially a fork of Postgres.
> Most CPUs will optimise away a simple if-test in various places.

Well, I assume SEPostgreSQL will rely on libraries that only exist on
SELinux, so I am afraid there will have to be some type of compile-time
flag, though the goal is to have as much of it enabled as possible at
the SQL level, as we have discussed and the patch reflects.

> Some users will be able to take advantage of the facilities without
> implementing full MLS. Yet we want the full facilities for Government.
> Many people currently run multiple customers in different schemas,
> though this would let them just run a single set of tables so is much
> better for running many small customers.
> 
> I'm very unhappy about putting a nonoptional value on tuple headers,
> especially because it is updatable. Do we expect MVCC will work with
> updatable security contexts? i.e. when you update the security context
> of a tuple that won't effect its visibility to existing system users. I
> can't imagine you'd want that would you? It's kind of difficult to *not*
> get it though.
> 
> Looks to me that this feature is useless without things working at row
> level. So we can't leave that part out.

Having the security column be optional is an interesting idea, perhaps
like we do with oids and with a GUC variable controlling the default. 

I think the patch itself is going to go through many adjustments before
application, I bet.

> The security context on each row could be an optional column present
> only if HEAP_HASSECURITYCONTEXT is set (0x0010 see htup.h), just like
> OIDs. Use a specific datatype rather than TEXT. That datatype could be
> an identifier to pg_security. Security people have big databases too, so
> we need to compress the security context more and take out parse time of
> string handling. Don't think we should use Oids, they're too big. Might
> be easier to use a 2byte field and restrict access to 32,000 contexts,
> which is easily enough. TEXT also makes me nervous, just in case there
> is some collation/encoding weirdness that allows contexts to be
> subverted. Fixed integers are hard to compromise in that respect.

I think the security mechanism is more complex than just assigning a
single security identifier, but perhaps not; I am unsure.

> How will unique indexes work? Do you implicitly add security context as
> last column on every unique index, or does the uniqueness violation only
> occurs within security contexts, or does the uniqueness violation tested
> against all contextx that the inserter can currently see? Is there a
> change to system catalogs? 
> 
> Foreign Key deletions could be handled correctly if you treat them as
> updates. If we have the following example
> 
> TableA
> security_context=y value=2 fk=1
> 
> TableB
> security_context=x value=1
> 
> TableA refers to TableB. Context x cannot see context y.

I think this is the "covert channel" we have been discussing.

> The interaction with SELinux should not be hardcoded. I think we need
> some form of plugin/wrapper to allow other systems to work. Not sure
> what those are, but this isn't a Linux only project. We want to give
> everybody the ability to work with PostgreSQL.

I think that is why the text security column was used, so other systems
could put their own security text in there.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +