Re: SE-PostgreSQL/Lite Review

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Joshua Brindle <method(at)manicmethod(dot)com>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SE-PostgreSQL/Lite Review
Date: 2009-12-11 20:13:10
Message-ID: 20091211201310.GC17756@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh,

* Joshua Brindle (method(at)manicmethod(dot)com) wrote:
> Stephen Frost wrote:
>> I do think that, technically, there's no reason we couldn't allow for
>> multiple "only-more-restrictive" models to be enabled and built in a
>> single binary for systems which support it. As such, I would make those
>> just "#if defined()" rather than "#elif". Let it be decided at runtime
>> which are actually used, otherwise it becomes a much bigger problem for
>> packagers too.
>
> It isn't just a case of using #if and it magically working. You'd need a
> system to manage multiple labels on each object that can be addressed by
> different systems. So instead of having an object mapped only to
> "system_u:object_r:mydb_t:s15" you'd also have to have it mapped to,
> eg., "^" for Smack.

I'm not sure I see that being a problem.. We're going to have
references in our object managers which make sense to us (eg: table
OIDs) and then a way of mapping those to some label (or possibly a set
of labels, as you describe). We might want to reconsider the catalog
structure a bit if we want to support more than one at a time, but I
don't see it as a huge problem to support more than one label existing
for a given object.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-12-11 20:14:36 Re: Adding support for SE-Linux security
Previous Message Tom Lane 2009-12-11 20:11:18 Re: [PATCH] dtrace probes for memory manager