OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Documentation/5555
Full headers

From: andrew.findlay@skills-1st.co.uk
Subject: authzTo ACL check for wrong principal
Compose comment
Download message
State:
1 replies: 1
11 followups: 1 2 3 4 5 6 7 8 9 10 11

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 13 Jun 2008 16:29:51 GMT
From: andrew.findlay@skills-1st.co.uk
To: openldap-its@OpenLDAP.org
Subject: authzTo ACL check for wrong principal
Full_Name: Andrew Findlay
Version: 2.4.10
OS: Linux: SuSE 10.2
URL: 
Submission from: (NULL) (88.97.25.132)


When using "authz-policy to" I find that the entity that is trying to do an
operation on behalf of another entity needs read access to its own authzTo
attribute.
This seems wrong: authzTo is defining what the user may do: I do not really want
them to be able to see it. When doing a proxy authz I think ACLs for this
attribute should not be checked at all as the access is effectively being done
by the rootdn.


Followup 1

Download message
Date: Sat, 14 Jun 2008 15:59:37 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: andrew.findlay@skills-1st.co.uk
CC: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
andrew.findlay@skills-1st.co.uk wrote:

> When using "authz-policy to" I find that the entity that is trying to do an
> operation on behalf of another entity needs read access to its own authzTo
> attribute.
> This seems wrong: authzTo is defining what the user may do: I do not really
want
> them to be able to see it. When doing a proxy authz I think ACLs for this
> attribute should not be checked at all as the access is effectively being
done
> by the rootdn.

AFAIK, access to that attribute is checked using AUTH rather than read. 
  The idea is that ACLs should allow to fine-grain control who is 
allowed to exploit the authorization feature while giving up as little 
as possible (e.g. AUTH instead of READ).

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   ando@sys-net.it
-----------------------------------



Followup 2

Download message
Date: Mon, 16 Jun 2008 13:33:07 +0100
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Pierangelo Masarati <ando@sys-net.it>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
On Sat, Jun 14, 2008 at 03:59:37PM +0200, Pierangelo Masarati wrote:

> AFAIK, access to that attribute is checked using AUTH rather than read. 
>  The idea is that ACLs should allow to fine-grain control who is 
> allowed to exploit the authorization feature while giving up as little 
> as possible (e.g. AUTH instead of READ).

You are right: if I just grant 'auth' access to 'authzTo' the proxy
authorisation succeeds. The philisophy makes sense so I will try to
come up with a suitable patch to the Admin Guide describing how to use
it. At the moment the only note about this is in the ACL Examples
(7.2.5 at present) which says that authentication/authorization
is always done anonymously - obviously not entirely true.

I am still a bit worried about the logic of the access test, as in my
enviroment I just had to grant the principal auth access to their own 
authzTo attribute to make proxy authorization work: the principal does
not even have 'disclose' access to their own entry or the parent
entry. Normally I would expect to need some level of access to
everything in the DN before I could make use of an attribute in an entry.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------



Followup 3

Download message
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Mon, 16 Jun 2008 14:45:43 +0200
To: andrew.findlay@skills-1st.co.uk
Cc: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
andrew.findlay@skills-1st.co.uk writes:
> You are right: if I just grant 'auth' access to 'authzTo' the proxy
> authorisation succeeds. The philisophy makes sense so I will try to
> come up with a suitable patch to the Admin Guide describing how to use
> it. At the moment the only note about this is in the ACL Examples
> (7.2.5 at present) which says that authentication/authorization
> is always done anonymously - obviously not entirely true.

If non-anonymous access is needed, the slapd.access(5) manpage needs an
update too.  (Or instead, to avoid duplicating text.)  Currently it just
says:

    Auth (=x) privileges are also required on the authzTo attribute
    of the authorizing identity and/or on the authzFrom attribute of
    the authorized identity.

but it doesn't mention to who needs that auth access.

-- 
Hallvard



Followup 4

Download message
Date: Mon, 16 Jun 2008 15:29:10 +0100
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
On Mon, Jun 16, 2008 at 02:45:43PM +0200, Hallvard B Furuseth wrote:

> If non-anonymous access is needed, the slapd.access(5) manpage needs an
> update too.  (Or instead, to avoid duplicating text.)  Currently it just
> says:
> 
>     Auth (=x) privileges are also required on the authzTo attribute
>     of the authorizing identity and/or on the authzFrom attribute of
>     the authorized identity.
> 
> but it doesn't mention to who needs that auth access.

It is the authenticated ID that needs access in both cases. On further
thought I think it is correct that the access is checked without
reference to whether that ID has access to entry and parent entries,
as (particularly in the case of authzFrom) the authenticated ID may
not have any direct access to the entry whose ID it is about to
assume.

Thus, if principal A has authenticated and wishes to perform an
operation using principal B's authorisation, the access required is:

	A needs auth access to authzTo in its own entry if that attribute
	is involved in giving A permission to act for B.

	A needs auth access to authzFrom in B's entry if that attribute
	is involved in giving A permission to act for B.

The rules are the same whether using a SASL authorization identity or
using a ProxyAuth control on an LDAP operation.

Thus I think my original report was wrong. This is a documentation
issue, not a bug.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------



Followup 5

Download message
Date: Mon, 16 Jun 2008 18:21:29 +0100
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote:

> Thus I think my original report was wrong. This is a documentation
> issue, not a bug.

I have uploaded a suggested set of patches to make the behaviour
clearer:

	ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch

The patch is against 2.4.10

It might be better still to factor out the concept of proxy
authorisation and its control from the SASL authz mechanism, as it
applies also to the LDAP Proxied Authorization Control.
I have not done this as I was unsure where best to put it.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------



Followup 6

Download message
Date: Mon, 16 Jun 2008 19:29:12 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: andrew.findlay@skills-1st.co.uk
CC: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
andrew.findlay@skills-1st.co.uk wrote:

> It might be better still to factor out the concept of proxy
> authorisation and its control from the SASL authz mechanism, as it
> applies also to the LDAP Proxied Authorization Control.
> I have not done this as I was unsure where best to put it.

Not sure what you mean there, but I believe the fact that the 
implementation is in saslauth.c is for mere historical reasons.  Right 
now, authorization code is independent from SASL, and is used by a 
number of features: SASL authz, RFC 4370, identity assertion, dgIdentity 
and more.

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   ando@sys-net.it
-----------------------------------



Followup 7

Download message
Date: Mon, 16 Jun 2008 19:01:39 +0100
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Pierangelo Masarati <ando@sys-net.it>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
On Mon, Jun 16, 2008 at 07:29:12PM +0200, Pierangelo Masarati wrote:

> Not sure what you mean there, but I believe the fact that the 
> implementation is in saslauth.c is for mere historical reasons.  Right 
> now, authorization code is independent from SASL, and is used by a 
> number of features: SASL authz, RFC 4370, identity assertion, dgIdentity 
> and more.

I was referring to documentation, where the only bit of the admin
guide that really talks about proxy authorisation is the SASL section.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------



Followup 8

Download message
Date: Mon, 16 Jun 2008 20:06:17 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
CC: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
Andrew Findlay wrote:

> I was referring to documentation, where the only bit of the admin
> guide that really talks about proxy authorisation is the SASL section.

Ah, OK.  Note that since some point in 2.3, authorization is described 
by a specific syntax <http://www.openldap.org/faq/data/cache/1254.html>, 
which should probably be advertised a bit more (and moved out from the 
experimental OID arc).

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   ando@sys-net.it
-----------------------------------



Followup 9

Download message
Date: Tue, 17 Jun 2008 09:21:53 +0100
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Pierangelo Masarati <ando@sys-net.it>
Cc: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote:

> Ah, OK.  Note that since some point in 2.3, authorization is described 
> by a specific syntax
<http://www.openldap.org/faq/data/cache/1254.html>, 
> which should probably be advertised a bit more (and moved out from the 
> experimental OID arc).

If that is used *everywhere* for authorisation then there could well
be more doc errors to correct. I am fairly sure I saw one place where
the docs specifically exclude some of those forms.

I notice that '*' excludes anonymous in this spec. There is an
undocumented option to 'allow' that seems relevant: proxy_authz_anon -
would allowing this cause anon to be included in '*' generally or is
it not that simple?

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------



Followup 10

Download message
Date: Tue, 17 Jun 2008 14:37:54 +0200
From: Pierangelo Masarati <ando@sys-net.it>
To: andrew.findlay@skills-1st.co.uk
CC: openldap-its@openldap.org
Subject: Re: (ITS#5555) authzTo ACL check for wrong principal
andrew.findlay@skills-1st.co.uk wrote:
> On Mon, Jun 16, 2008 at 08:06:17PM +0200, Pierangelo Masarati wrote:
> 
>> Ah, OK.  Note that since some point in 2.3, authorization is described 
>> by a specific syntax
<http://www.openldap.org/faq/data/cache/1254.html>, 
>> which should probably be advertised a bit more (and moved out from the 
>> experimental OID arc).
> 
> If that is used *everywhere* for authorisation then there could well
> be more doc errors to correct. I am fairly sure I saw one place where
> the docs specifically exclude some of those forms.

Yes, I believe in some cases some of the variants of the syntax are not 
allowed.  This is true, for example, in SASL identity mapping, which 
does not allow the regex, subtree, children, onelevel, group and users 
styles, only the base and uri forms are allowed (provided the latter 
only returns a single match).

> I notice that '*' excludes anonymous in this spec. There is an
> undocumented option to 'allow' that seems relevant: proxy_authz_anon -

Why undocumented?  It is documented (in 2.4, at least; it does not exist 
for 2.3).

> would allowing this cause anon to be included in '*' generally or is
> it not that simple?

'*' implies a non-empty value; to include anonymous, use "dn.regex:.*", 
or "dn.subtree:".

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   ando@sys-net.it
-----------------------------------



Followup 11

Download message
Date: Mon, 09 Feb 2009 22:59:43 +0100
From: Pierangelo Masarati <ando@sys-net.it>
To: Gavin Henry <openldap-its@OpenLDAP.org>
CC: openldap-its@OpenLDAP.org
Subject: Re: authzTo ACL check for wrong principal (ITS#5555)
Gavin Henry wrote:
>> On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote:
>>
>>> Thus I think my original report was wrong. This is a documentation
>>> issue, not a bug.
>> I have uploaded a suggested set of patches to make the behaviour
>> clearer:
>>
>> 	ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch
>>
>> The patch is against 2.4.10
>>
>> It might be better still to factor out the concept of proxy
>> authorisation and its control from the SASL authz mechanism, as it
>> applies also to the LDAP Proxied Authorization Control.
>> I have not done this as I was unsure where best to put it.
> 
> Hi Ando,
> 
> If you get a chance at some point, could you review this patch and I'll
apply it
> etc.

After a quick look, it seems to be a good starting point.  I'd be a 
little bit more careful about wording: "proxyAuthz" should probably be 
"proxied authorization"; the first time it is mentioned, a reference to 
RFC4370 should be present, both in slapd.access(5) and in the Admin 
Guide (as in the SASL section).

Also, in the contribution to the Admin Guide it is sometimes referred to 
as the "proxy facility"; I'd rather use "proxied authorization facility" 
or better "proxied authorization control".

Finally, the patch seems to correctly explain what is required in order 
to authorize.  I'd add a strong comment on the importance to protect 
authzFrom and especially authzTo from malicious writes, that could 
result in lesser privileged identities to modify their own entry in 
order to be able to self-authorize as higher privileged identities. 
Administrators should be warned as they start reading about this feature.

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------



Reply 1

Resend
From: Gavin Henry <openldap-its@OpenLDAP.org>
To: ando@sys-net.it
Subject: Re: authzTo ACL check for wrong principal (ITS#5555)
Date: Mon Feb  9 16:01:30 2009
CC: openldap-its@openldap.org
> On Mon, Jun 16, 2008 at 02:29:21PM +0000, Andrew Findlay wrote:
> 
>> Thus I think my original report was wrong. This is a documentation
>> issue, not a bug.
> 
> I have uploaded a suggested set of patches to make the behaviour
> clearer:
> 
> 	ftp://ftp.openldap.com/incoming/andrew.findlay-20080616.patch
> 
> The patch is against 2.4.10
> 
> It might be better still to factor out the concept of proxy
> authorisation and its control from the SASL authz mechanism, as it
> applies also to the LDAP Proxied Authorization Control.
> I have not done this as I was unsure where best to put it.

Hi Ando,

If you get a chance at some point, could you review this patch and I'll apply it
etc.

Thanks,

Gavin.

Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org