On Tue, Jan 10, 2012 at 6:28 AM, Kohei KaiGai <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
