[v9.2] Add GUC sepgsql.client_label

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.

Thanks,

[*1] CAC - Common Access Card
http://en.wikipedia.org/wiki/Common_Access_Card
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>