Re: [v9.2] Add GUC sepgsql.client_label

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: PgHacker <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <jbrindle(at)tresys(dot)com>
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Date: 2012-01-26 17:24:55
Message-ID: CA+TgmoY4DOantFmQDGR-jVtH4QDPM7NRucf0i5AVo7fThrKW5Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 10, 2012 at 6:28 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> This patch adds a new GUC "sepgsql.client_label" that allows client
> process to switch its privileges into another one, as long as the
> system security policy admits this transition.
> Because of this feature, I ported two permissions from "process" class
> of SELinux; "setcurrent" and "dyntransition". The first one checks
> whether the client has a right to switch its privilege. And the other
> one checks a particular transition path from X to Y.
>
> This feature might seem to break assumption of the sepgsql's security
> model. However, single-directed domain transition from
> bigger-privileges to smaller-privileged domain by users' operation is
> also supported on operating system, and useful feature to restrict
> applications capability at beginning of the session.
>
> A few weeks ago, I got a requirement from Joshua Brindle. He is
> working for Web-application that uses CAC (Common Access Card) for its
> authentication, and wanted to integrate its security credential and
> security label of selinux/sepgsql.
> One problem was the system environment unavailable to use
> labeled-networking (IPsec), thus, it was not an option to switch the
> security label of processes on web-server side. An other solution is
> to port dynamic-transition feature into sepgsql, as an analogy of
> operating system.
>
> An expected scenario is below:
> The web-server is running with WEBSERV domain. It is allowed to
> connect to PostgreSQL, and also allowed to invoke an trusted-procedure
> that takes an argument of security-credential within CAC, but, nothing
> else are allowed.
> The trusted-procedure is allowed to reference a table between
> security-credential and security-label to be assigned on, then it
> switches the security label of client into CLIENT_n.
> The CLIENT_n shall be allowed to access tables, functions and others
> according to the security policy, and also allowed to reset
> "sepgsql.security_label" to revert WEBSERV. However, he is not
> available to switch other domain without security-credential stored
> within CAC card.
>
> I and Joshua agreed this scenario is reasonable and secure.
> So, we'd like to suggest this new feature towards v9.2 timeline.

I'm wondering if a function would be a better fit than a GUC. I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that. I think. But if you expose a function then it can work
however you like.

On another note, this is an awfully large patch. Is there a separate
patch here that just does code rearrangement that should be separated
out?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2012-01-26 17:36:15 Re: Simulating Clog Contention
Previous Message Vik Reykja 2012-01-26 17:02:09 Re: Different error messages executing CREATE TABLE or ALTER TABLE to create a column "xmin"