Handling of private/confidential groupware objects
martin.konold at erfrakon.de
Thu Jan 26 05:12:13 CET 2006
Am Mittwoch, 25. Januar 2006 12:37 schrieb Bernhard Reiter:
I am unhappy how the discussion with you is evolving! It is counterproductive
and wasting my time :-(
> Am Montag, 23. Januar 2006 23:29 schrieb Martin Konold:
> > Am Montag, 23. Januar 2006 09:58 schrieb Bernhard Reiter:
> > > This cannot be guarenteed as long as clients can set the ACL
> > > of all the folders. A user _could_ set the ACL of the hidden folder
> > > differently. Or do you think that we should add more protection
> > > to the imapd implementation then?
> > Well, if users shoot themself in the foot we cannot prevent them from
> > doing so in the good old unix tradition. Though we could apply "self
> > healing" semantics to the Kolab clients which can "fix" the wrong ACLs.
> > IMHO trying to prevent intentional shooting the foot will in the end
> > require TPM like architectures.
> well this is a general type argument which can be used in any direction.
> We are discussing the how to make a good solution which is easy
> enough to understand and use so that people will not shoot them
> in their feet.
This is nonsense. The "hidden" folders are hidden by default this means they
are typically _not_ listed by Kolab clients and therefore are typically _not_
prone to unintentional ACL changes by the user.
If a user chooses to use a non Kolab tool e.g. some arbitrary 3rd party client
with IMAP ACLs setting capabilites and chooses to mess with the ACLs on the
hidden folders (most don't allow _any_ ACL operations...) it is shooting
herself in the foot.
Calling my proposal a security issue due to the fact that users can use some
non Kolab tool to actively set an ACL for other users/groups which allows
access to formerly nonaccessable private data is ridiculous!.
You: It hurts horribly if I go to the weapons shop, buy a gun, point at my
foot and pull the trigger.
Doctor: Well, a gun is a powerful tool. You have multiple choices here. Either
don't obtain a gun or avoid pointing at your foot and last but not least
never pull the trigger when pointing at your foot.
Being able to use a 3rd party tool to grant _explicit_ access for a resource
is no security problem but getting a gun, pointing at your foot and
_intentionally_ pulling the trigger.
(This is equivalent to a user explicitly granting someone read access to a gpg
private key or some socket in the unix filesystem.)
The real problem with you is that you are mixing different issues in this
thread and try to solve different non topic issues while dilluting the
I am talking about "Handling of private/confidential groupware objects" and
you seem to discuss other unrelated issues like "private freebusy", group
The most obscure stuff from you is:
> Thinking about this, this clearly speaks in favour of doing the sync
> with the server. This is what users want anyway and then we are not
> bound on the current sync code limitations.
This is nonsense!
The technically challenge does not in any way become easier when doing the
sync of PDAs with the Kolab server compared to the Kolab client. Actually it
is more complicated not less complicated.
In contrast what you seem to assume doing the sync directly with the server
(e.g. sync-ml) does _not_ grant us more control!
(This is partly due to the fact that we still don't have control about the
sync algorithm implemented on the PDA)
Last but not least this does not mean that I am agains implementing direct PDA
sync with the server in the future but doing so does not solve the
private/confidential groupware objects issue.
> As far as I have thought, I think that the problem with
> one-calendar-only PDAs can be solved on the sync code level.
Only if you are willing to create your own PDA specific sync sw. (No I am not
up volunteer to create this....)
> Encryption on the emails using S/MIME or OpenPGP would protect
> against administrator, too.
You seem to be citing poor Schneier for your nonsense. Of course using
encryption in a corporate environment does _not_ protect from malicious
administrators. It is helpful for other purposes though. E.g. it helps to
protect stolen media (like backup tapes or harddisks).
> which means we cannot guarantee that a hidden folder is "private"
> to the ower of the folder in all cases on the server, it depends on the ACL
> of the hidden folder.
Which is perfectly fine from a security POV!
> This question was is one aspect,
> and yes it is an aspect against your proposal.
It was nonsense and wasting my time.
> However this always needs to be weighted with all aspects.
> I have not disregarded your proposal yet,
Fortunately it is not up to you to make such technical decissions. It is your
job to do the _non-technical_ project management.
Dilbert comes to my mind.....
> but with my current knowledge, I think
> the other solution is better.
You did _never_ proposed another technical solution! You only raised some
points which you would love to have also been solved and provided some non
technical proposal how to circument the issue on a procedural/social
There are currently no other solutions than those I proposed at the beginning
of this mail thread on November 30th in 2005.
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
More information about the format