Re: forcing encryption for external server access while allowing unencrypted localhost connections

[Dieter Kluenter <dieter@dkluenter.de>]

Hi,

"Richard L. Goerwitz III" <richard@Goerwitz.com> writes:

> Dieter Kluenter wrote:

>> Think about a rule something like
>> ,----[ rule design ]
>> | access to a subtree
>> |     by an authenticated distinguished name with sasl_ssf=a
>> |         and |          if local socket with transport_ssf=x
>> |           grant privilege
>> |          if local network with transport_ssf=y
>> |           grant privilege
>> |          if public network with tls_ssf=z
>> |           grant privilege
>> |         else
>> |     grant privilege
>> |    stop
>> `----
>
> Two comments:
>
>    1) The issue is that Chris (and others, it turns out) could
>       really use a way to assign SSFs to sessions over specific
>       transports or connections to/from specific peers - and do
>       it at startup time from the slapd.conf file

right, that is handled by a peer based rule set or by transport
controls, see man slapd.access(5)

>    2) The scenario you outline above solves this problem very
>       indirectly; it would be better if there were a direct
>       solution

Frankly, I don't get your point here.

>    3) Correct me if I'm wrong, but in your scenario we're still
>       only talking about access to objects, not about operations
>       like doing a bind; again, it's at best an indirect way of
>       getting what Chris wants (and therefore a lot more complex
>       than it needs to be, and I'm not entirely sure it will
>       always block the initial bind; rather it will block the
>       object access)

Here I have to correct you. the above scenario describes the rules
that apply to bind requests to one or more objects and the privileges
granted to manipulate this objects. 

> This isn't a critique, by the way.  I'm just pointing out that
> there's an unfulfilled need here that could be translated into
> a feature request of some kind.

If I understand you correctly, you are requesting a session that is
permanently open for a given period based on the initial bind request,
and subsequent requests are answered without any further privilege
controls but a sort of session granting ticket.
I don't think this would be a wise feature, but others may comment on
this.

-Dieter
 
-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8C183C8622115328