[Kolab-devel] Re: Free busy, security considerations

[Bernhard Reiter]

On Tuesday 31 August 2004 10:58, Stephan Buys wrote:
> As far as security is concerned - we already have a daemon that has manager
> access to all the folders, so what is the issue?

It is a smaller security issue and it arises from the fact
that you want to minimise the number of code lines that are executed
with permissions.

Within the Proko2 projects we are quite sequrity aware
which also included the ability of the user to choose what will happen
with his/her data. This includes the possibility to keep local folders
and have folders that no other user of the system has read permissions to.

The Kolab daemon is a lot smaller and easier to security screen
as the freebusy creation code based on Horde and PHP.

If we can have a solution where only the credentials of one user
are given at a time where a pfb is created on the server, this limits
the possibilities of attacking this pfb creation script a bit, too.
Many attacks on tricking the script to deal with other folders data
an reveal them will not work. You would need a complete crack
and collection credentials before you could access another others data.

> On Monday 30 August 2004 10:39, Bo Thorsen wrote:
> > If it's required to keep all calendar
> > stuff in IMAP folders, we would have a possibility to make an FB list
> > creation daemon on the server that would construct the FB lists from the
> > IMAP folder info. We have PHP code that can do this (needed for
> > car/room/... resources anyway), but it's not a good solution. At least
> > for Kontact, it's possible to connect to a lot of different servers, you
> > can have calendar info in several local files, and more. And having a
> > daemon with rights to read all calendar folders sounds like a big
> > security issue.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20040901/63fd8dd5/attachment.p7s>