Handling of private/confidential groupware objects

[Martin Konold]

Am Mittwoch, 25. Januar 2006 12:37 schrieb Bernhard Reiter:

Hi Bernhard,

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 
current discussion.

I am talking about "Handling of private/confidential groupware objects" and 
you seem to discuss other unrelated issues like "private freebusy", group 
calendars,....

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 
level......

There are currently no other solutions than those I proposed at the beginning 
of this mail thread on November 30th in 2005.

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker