On Tue, Jan 10, 2012 at 6:28 AM, Kohei KaiGai <kaigai@kaigai.gr.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
