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

2012/3/20 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Fri, Mar 16, 2012 at 3:44 AM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>> In the patch with copy-editing documentation following that commit, at "in
>> at their option", s/in// ?
>
> Oh, yeah.  Oops.  Thanks.
>
>> Also 'rather than .. as mandated by the system':
>> I'm having trouble parsing 'as'. It is also unclear to me what 'system'
>> means: selinux or PostgreSQL, or both? I suspect it is PostgreSQL, since
>> selinux is still enforcing / 'mandating' it's policy. What about "rather
>> than that the switch is controlled by the PostgreSQL server, as in the case
>> of a trusted procedure."
>
> Well, I think it's both.  PostgreSQL is responsible for enforcing
> privileges on database objects, but it relies on SE-Linux to tell it
> whether a given access is allowable.  So, from PostgreSQL's point of
> view, it's delegating the decision to SE-Linux.  But SE-Linux views
> itself as a mechanism for enforcing a system-wide security policy, so
> views PostgreSQL as an instrument for carrying out its access control
> goals.  I don't know how to disentangle that.  I'm actually not
> entirely sure that I even believe the underlying sentiment that
> dynamic transitions are dangerous.  Maybe KaiGai could comment further
> on what we should be trying to convey here.
>
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.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>