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

On Wed, Mar 21, 2012 at 6:07 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> The reason why dynamic domain transition should be configured
> carefully is that it partially allows users to switch their own privileges
> in discretionary way, unlike trusted procedure.
>
> The original model of selinux on operating system assumes all the
> domain transition shall happen on execve(2) time, but it made clear
> some sort of application is not happy with traditional fork - exec
> lifecycle, such as web server, connection pooling software, or others.
>
> Even as they perform according to the operations from users,
> it does not fork - exec itself because of some reason, typically
> performance. One point we should focus on is these applications
> have relatively trustable portion and untrustable one.
>
> The dynamic domain transition was designed to "restrict" privileges
> more than the current one on the trustable portion, prior to launch
> untrustable one. So, it never intend to switch client domain with
> 100% arbitrary. Its bottom line is restricted with the security policy;
> that explicitly describes the range of domains being allowed to
> translate.
>
> So, we will be able to conclude dynamic domain transition is
> harmless as long as it works to reduce privileges; that should
> be guaranteed with the security policy.
> It also means sepgsql_setcon() is harmless as long as it works
> according to the decision of SELinux.
>
> The connection pooling software scenario using trusted procedure
> might be a bit confusing. In this case, the client domain is once
> switched to the trusted one with mandatory way, then it switches
> to more restricted domain in arbitrary way; thus, it is not allowed
> to promote its privileges in arbitrary way.
> We assume the trusted procedure is a enough small portion to
> ensure bug or vulnerability free.
>
> Joshua, please add some comments, if you have.

I guess my feeling on this is that the warning in the documentation
isn't really helping anything here. I mean, we don't need to document
that allowing people to give themselves more privileges is a security
hole; that much is obvious.

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