Issue 5555 - authzTo ACL check for wrong principal
Summary: authzTo ACL check for wrong principal
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: documentation (show other issues)
Version: 2.4.10
Hardware: All All
: --- normal
Target Milestone: 2.6.0
Assignee: Quanah Gibson-Mount
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-13 16:29 UTC by Andrew Findlay
Modified: 2021-10-25 22:05 UTC (History)
0 users

See Also:


Attachments
20080616 proposed patch (5.09 KB, patch)
2021-07-09 18:33 UTC, Quanah Gibson-Mount
Details

Note You need to log in before you can comment on or make changes to this issue.
Description Andrew Findlay 2008-06-13 16:29:51 UTC
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.

Comment 1 ando@openldap.org 2008-06-14 13:58:55 UTC
changed notes
Comment 2 ando@openldap.org 2008-06-14 13:59:37 UTC
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
-----------------------------------

Comment 3 Andrew Findlay 2008-06-16 12:33:07 UTC
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     |
-----------------------------------------------------------------------

Comment 4 Hallvard Furuseth 2008-06-16 12:45:43 UTC
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

Comment 5 Andrew Findlay 2008-06-16 14:29:10 UTC
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     |
-----------------------------------------------------------------------

Comment 6 Hallvard Furuseth 2008-06-16 15:29:28 UTC
moved from Incoming to Documentation
Comment 7 Andrew Findlay 2008-06-16 17:21:29 UTC
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     |
-----------------------------------------------------------------------

Comment 8 ando@openldap.org 2008-06-16 17:29:12 UTC
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
-----------------------------------

Comment 9 Andrew Findlay 2008-06-16 18:01:39 UTC
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     |
-----------------------------------------------------------------------

Comment 10 ando@openldap.org 2008-06-16 18:06:17 UTC
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
-----------------------------------

Comment 11 Andrew Findlay 2008-06-17 08:21:53 UTC
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     |
-----------------------------------------------------------------------

Comment 12 ando@openldap.org 2008-06-17 12:37:54 UTC
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
-----------------------------------

Comment 13 Gavin Henry 2009-02-09 16:01:30 UTC
> 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.
Comment 14 ando@openldap.org 2009-02-09 21:59:43 UTC
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
-----------------------------------

Comment 15 OpenLDAP project 2014-08-01 21:04:08 UTC
feature requires AUTH rather than READ
Comment 16 Quanah Gibson-Mount 2021-07-09 18:33:17 UTC
Created attachment 830 [details]
20080616 proposed patch
Comment 18 Quanah Gibson-Mount 2021-07-26 23:17:11 UTC
Commits: 
  • 73e7034d 
by andrew.findlay@skills-1st.co.uk at 2021-07-26T22:02:55+00:00 
ITS#5555 - Correct documentation for SASL AuthzTo Check