Insecure configuration example on LDAP authentication wiki page #1947
Description
The wiki page LDAP authentication states:
You can use the group membership also for managing the rights. For example you want to give everyone read rights to the group calendars in which he is a member and write access to the member of the group administrators. This can you achieved with following rules:
[calendarsWriter] groups: administrators collection: GROUPS/[^/]+ permissions: rw [calendarsReader] user: .+ collection: GROUPS/[^/]+ permissions: rImportant The members of the group administrators have only write access to the group calendars in which he is a member.
Example of being able to write to any group's calendar
Even though the wiki states "the members of the group administrators have only write access to the group calendars in which he is a member", this is not the case.
In my case I used the rule from the wiki matching on superheros rather then administrators.
The debug log shows even though the hackers user is not a member of staff they can still write to that calendar (base64 for staff being c3RhZmY=):
Log
[INFO] PUT request for '/GROUPS/c3RhZmY=/a7f477fe-4079-4ae4-a9d3-9e3379b8044b.ics' received from 127.0.0.1 using 'curl/8.15.0'
[DEBUG] Request header: suppressed by config/option [logging] request_header_on_debug
[DEBUG] Sanitized path: '/GROUPS/c3RhZmY=/a7f477fe-4079-4ae4-a9d3-9e3379b8044b.ics'
[DEBUG] _login2 ldap://localhost:3893, cn=serviceuser,ou=svcaccts,dc=glauth,dc=com
[DEBUG] _login2 login escaped for LDAP filters: hackers
[DEBUG] _login2 found LDAP user DN cn=hackers,ou=superheros,ou=users,dc=glauth,dc=com
[DEBUG] _login2 LDAP groups of user: superheros
[DEBUG] _login2 hackers successfully authenticated
[DEBUG] Groups received from LDAP: 'superheros'
[INFO] Successful login: 'hackers' (ldap)
[DEBUG] logging of rules which doesn't match suppressed by config/option [logging] rights_rule_doesnt_match_on_debug
[DEBUG] Rights: 'hackers':'GROUPS/c3RhZmY=/a7f477fe-4079-4ae4-a9d3-9e3379b8044b.ics' doesn't match any section
[DEBUG] logging of rules which doesn't match suppressed by config/option [logging] rights_rule_doesnt_match_on_debug
[DEBUG] Rule 'hackers':'GROUPS/c3RhZmY=' matches '':'GROUPS/[^/]+' from section 'calendarsWriter' permission 'rw' by group membership
[DEBUG] Request content: suppressed by config/option [logging] request_content_on_debug
[DEBUG] PUT request contains item with UID 'a7f477fe-4079-4ae4-a9d3-9e3379b8044b' size 265 below limit 10000000: '/GROUPS/c3RhZmY=/a7f477fe-4079-4ae4-a9d3-9e3379b8044b.ics'
[DEBUG] Response header: suppressed by config/option [logging] response_header_on_debug
[INFO] PUT response status for '/GROUPS/c3RhZmY=/a7f477fe-4079-4ae4-a9d3-9e3379b8044b.ics' in 0.031 seconds: 201 Created
Example of being able to read any group's calendar
Even though the groups the user is not a member of don't show up on the PROPFIND (which may be the source of this confusion), you can still access the calendars directly if you know the group name.
Here is a sample debug log showing even though the hackers user is not a member of staff they can still access that calendar, allowed by the rule included in the wiki page.
Log
[INFO] REPORT request for '/GROUPS/c3RhZmY=' received from 127.0.0.1 using 'curl/8.15.0'
[DEBUG] Request header: suppressed by config/option [logging] request_header_on_debug
[DEBUG] Sanitized path: '/GROUPS/c3RhZmY='
[DEBUG] _login2 ldap://localhost:3893, cn=serviceuser,ou=svcaccts,dc=glauth,dc=com
[DEBUG] _login2 login escaped for LDAP filters: hackers
[DEBUG] _login2 found LDAP user DN cn=hackers,ou=superheros,ou=users,dc=glauth,dc=com
[DEBUG] _login2 LDAP groups of user: superheros
[DEBUG] _login2 hackers successfully authenticated
[DEBUG] Groups received from LDAP: 'superheros'
[INFO] Successful login: 'hackers' (ldap)
[DEBUG] logging of rules which doesn't match suppressed by config/option [logging] rights_rule_doesnt_match_on_debug
[DEBUG] Rule 'hackers':'GROUPS/c3RhZmY=' matches '.+':'GROUPS/[^/]+' from section 'calendarsReader' permission 'r'
[DEBUG] Request content (XML): suppressed by config/option [logging] request_content_on_debug
[DEBUG] Response content (XML): suppressed by config/option [logging] response_content_on_debug
[DEBUG] Response header: suppressed by config/option [logging] response_header_on_debug
[INFO] REPORT response status for '/GROUPS/c3RhZmY=' in 0.019 seconds plain 663 bytes (getetag): 207 Multi-Status
I can't work out how to provide an equivalent safe rule given the collection names for LDAP groups are base64 encoded so they can't be matched in the usual way.