Baikal: Shared calendars / contacts and fine grained permissions

[netgusto]

B2 should really support these !

[schmidp]

is this something the development version already supports?

[mrbaseman]

for managing the permissions to calendars across user accounts in Baikal 0.2.7 I have written a script: https://github.com/mrbaseman/calendar-tools/blob/master/permissions.php (just leaving this comment here for others who are searching for such a tool and stumble across this ticket)

[SamuelMoraesF]

Would be fantastic an option to share calendars with public link(read-only mode, without login)

[mrbaseman]

actually, this is a special case included in my script. Just add a user, let's call him "web" and assign a simple password to him (e.g. "readonly" - it doesn't matter at all) and remove the default calendar and carddav ressource. So, the user web has no writable ressources at all. Then, use my script to grant him read-access to other user's calendars. The link to access the default calendar of user called "user" is: http://web:[email protected]/baikal/cal.php/calendars/user/default

[dakira]

@mrbaseman, thanks for this! Exactly what I was looking for! Just a hint through: You should start to get used to PDO and use prepared statements to prevent SQL injections.

[mrbaseman]

@dakira,

Just a hint through: You should start to get used to PDO and use prepared statements to prevent SQL injections.
Thanks for the hint. I have been thinking about it for a while, but I
don't quite understand how SQL injections would be an attack vector in
this case. The first thing I do (after including some definitions), is
to check if the user is properly authenticated as admin and I check the
password hash. Without knowledge of that, the script exits in the first
place. Note that the credentials are not stored in the database. They
are defined in constants to which I compare the input coming from the
web server. Only, if this is correctly verified, a connection to the
database is opened.
Then, if you are already authenticated as admin, you anyway have full
access and there is no need to protect against SQL injections. Note:
there is no code sent to the browser for local execution (Javascript and
the like), so also no danger from XSS.

[dakira]

@mrbaseman it's just a weak link that's avoidable. If you look at the recent Magento attack you'll see that every individual component was secure and well thought out. There were several issues that couldn't be used for an attack individually. Only chained together, an attack was possible. Not using prepared statements could be part of such a chain (even if you can't see an attack yet).

[zot24]

How @netgusto are you going to implement the sharing addressbooks between users for a CardDav server?

I was just having a look to your code on BaikalModelBundle and I was wondering if you are gonna use GroupMembers as a kind of pivot table to handle the relations between the principals (users) and the principals (groups of users) to achieve the sharing of an addressbook between the members of a group.

btw great project thanks

[m0yellow]

@mrbaseman there is no excuse for not using prepared statements, also in the admin menu.
To illustrate that think the following example: even with XSRF, cookie leak or man-in-the-browser attack you could still implement read/export limit, strong history, query log, and the attack surface would be much smaller. If I can hijack the admin with a simple phishing link, I could download and delete the whole calendar in most companies, as there tend to be more admins than needed for install (e.g. HR, for assigning rights).

TL;DR: +1 for proper permission handling in Baikal, as this is the backbone for professional use-cases.

[mrbaseman]

@Matthias first of all, note that I only have provided the user
management script as a workaround. I haven't been working on other
things concerning the admin menu, yet (because I didn't have the time to
learn how to use the Flake class framework.

Coming back to your main point about prepared statements in the
permission administration script: prepared statements help against first
order sql injections when user supplied data is used in queries. But
that's not the case here. I have queries without user-supplied
components to build up the lists of users, groups, and permissions. Only
these IDs are compared to the posted values. For setting the permissions
I also don't use the posted variables directly in the queries. I only
use them to decide which 'if'-branch to go. The statement itself again
is based on values originally coming directly out of the database. So,
prepared statements would not improve anything here, because the attacks
prevented by prepared statements wouldn't be successful anyway. Prepared
statements also wouldn't help against a man in the browser attack.
Thee is already some protection in place against taking over the admin
session, because the hash value contains the client IP and it expires
every midnight.

Anyhow, I can rewrite the script with prepared statements. It seems that
this is a strong desire for some users...

[m0yellow]

thanks for your lengthy and elaborated reply,
as I came here via google, I wanted to give advice more for the anonymous reader.

Please take it as a reference to best current practice.
I appreciate your work, and my ideas about probing and take overs are only from the daily reading at my abuse@ address.

On 09 Jan 2016, at 21:09, Martin Hecht [email protected] wrote:

@Matthias first of all, note that I only have provided the user
management script as a workaround. I haven't been working on other
things concerning the admin menu, yet (because I didn't have the time to
learn how to use the Flake class framework.

Coming back to your main point about prepared statements in the
permission administration script: prepared statements help against first
order sql injections when user supplied data is used in queries. But
that's not the case here. I have queries without user-supplied
components to build up the lists of users, groups, and permissions. Only
these IDs are compared to the posted values. For setting the permissions
I also don't use the posted variables directly in the queries. I only
use them to decide which 'if'-branch to go. The statement itself again
is based on values originally coming directly out of the database. So,
prepared statements would not improve anything here, because the attacks
prevented by prepared statements wouldn't be successful anyway. Prepared
statements also wouldn't help against a man in the browser attack.
Thee is already some protection in place against taking over the admin
session, because the hash value contains the client IP and it expires
every midnight.

Anyhow, I can rewrite the script with prepared statements. It seems that
this is a strong desire for some users...

—
Reply to this email directly or view it on GitHub.

[evert]

This issue was moved to fruux/Baikal2#30

[lkraav]

Since this repo just got a fresh pre-release, which repo and issue about sharing should one follow?

[evert]

Sharing in baikal 0.x will land when this PR lands: https://github.com/fruux/sabre-dav/pull/696

[vbmit3]

@mrbaseman
Is your script supposed to work for addressbooks too?
I'm in dire need of making a "shared" RO addressbook in baikal 0.2.7, while leaving the others RW.
This script seems to take care of calendars, but it doesn't seem to work for addressbooks.
Any help would be appreciated, thanks.

[mrbaseman]

@vbmit3
since my script makes use of the calendar-proxy-read and calendar-proxy-write principals it only works for the calendars. The principals in sabre-io are something like objects to assign permissions. Perhaps it is possible to do something similar for addressbooks, but I haven't seen anything like "addressbook-proxy" principals so far.

With a newer sabre/dav versions, as shipped with Baikal 0.4.6 for instance, there is a property "d:acl" on the addressbooks however, which contains "d:read" and "d:write" for the owner of the collection. A first step would be to experiment with a dav client (cadaver for instance) and add appropriate properties to the webdav directory. I'm not sure if this helps reading the files therein. Maybe they inherit the acls from the directory when they are created after the acls were set, so this could be a road to go, but I haven't used the address books much yet (I have just started working on this topic by coincidence these days).

Apart from that, a simple approach could be a cron job running somewhere, that synchronizes the addressbooks occasionally. It would have to list the entries in the addressbook that you would like to share "readonly" and copy them to an empty local directory. Next it would have to remove all entries from a different webdav directory and synchronize the local directory again to that remote place. From a security point of view this would be the same as a readonly share. From the users perspective the client would miss the feedback of an error message when it tries to modify the readonly share. It would be able to do so and, well, those changes would get lost in the next synchronization (if the client notices it, depends on how the time stamps are handled during the synchronization - in the context of vcards you might have to update the REV property each time you run the synchronization).

[dakira]

@evert please re-open this issue. baikal2 development is halted.

[jamesquilty]

I've been using Baikal 0.2.7 with the calendar-tools permissions patch written and linked by @mrbaseman in https://github.com/sabre-io/Baikal/issues/303#issuecomment-77707457 without problems. Thanks to all concerned.

I'd like to upgrade to the latest version of Baikal, but it's very unclear whether the PR referenced by @evert in https://github.com/sabre-io/Baikal/issues/303#issuecomment-184374642 in 2016 was ever merged, or whether the "calendar sharing plugin" mentioned in the CHANGELOG entry for version 0.6.0 provides the same functionality as calendar-tools.

Could someone please advise whether the calendar sharing plugin present in version 0.6.0 and later provides the same functionality as calendar-tools?

[jamesquilty]

So, I upgraded to 0.6.1 and it's a "good news, bad news" situation.

The good news (relatively speaking) is that the migration of my 0.2.7 calendars shared with the calendar-tools permissions propagated the shared permissions. This means that the upgrade didn't break my existing calendar access.

The bad news is that I'm worse off under 0.6.1 with regard to shared calendars because I've lost the ability to use calendar-tools to set read/write access to calendars on another user's account _and_ there's no interface in Baikal 0.6.1 to set these permissions.

I use Thunderbird/Lightning and it's very difficult to connect to multiple CalDAV accounts. It's not obvious to me that, even if I am able to connect as the user who owns the calendars I wish to share, that Thunderbird's "Delegate calendar" feature will give read/write access to others in the same way that calendar-tools provided.

While it's claimed that calendar sharing is implemented as of 0.6.0, how is this feature used?

[dakira]

@jamesquilty I gave up and installed Nextcloud which is based on SabreDAV and has perfect calendar sharing funcitonality built in.

[jamesquilty]

I resolved the immediate problem I had, which was how to grant read-only or read-write access to all the calendars of a new user I created named Shared. I created the new user via the Baikal interface then used phpliteadmin to inspect the database to understand how the description of calendar-proxy https://sabre.io/dav/caldav-proxy/ works in practice. Thanks are due again to @mrbaseman for writing the permissions.php script, it was very helpful in providing a database with principals and groupmembers database tables already set up and populated, and understanding how to add the appropriate id numbers from the principals table to new rows in groupmembers by phpliteadmin.

I've written notes on how to do this, for my own reference, and I'm happy to describe the process in more detail if anyone is interested.

[tuxtlequino]

I've written notes on how to do this, for my own reference, and I'm happy to describe the process in more detail if anyone is interested.

I would be very interested. If you post that here I am sure it will Also be of use to someone like me following a rabbit trail all over the issues without going somewhere else.

[ByteHamster]

While it's claimed that calendar sharing is implemented as of 0.6.0, how is this feature used?

Calendar sharing is not available from the normal Baikal admin interface. We just enabled this feature in the sabre/dav library. For details on how to use the feature, have a look here: https://github.com/sabre-io/Baikal/issues/875