[Kolab-devel] setting allowcrossdomainacls yes

[Jeroen van Meeuwen (Kolab Systems)]

Gavin McCullagh wrote:
> Hi,
> 
> On Fri, 27 Aug 2010, Jeroen van Meeuwen (Kolab Systems) wrote:
> 
> > I'm interested in what your actual use-case is; Let me try and phrase a 
few 
> > scenarios that I can think of, this patch would be useful for;
> > 
> > user at country1.company.com versus user at country2.company.com
> > user at company.country1 versus user at company.country2
> 
> We have a college made up of three smaller colleges, each with their own
> domain.  They could be on one domain really, but for various reasons, each
> has its own domain.  So we have 
> 	
> 	user at college1.tld
> 	user at college2.tld
> 	user at college3.tld
> 
> We have each domain hooked up nicely for email, we'd just like to be able
> to share folders between them, particularly for calendars and contacts.
> 

That's understandable.

> > But the patch / feature implementation may most definitely not allow the 
> > following to happen:
> > 
> > ceo at novell.com versus lawyer at sco.com
> 
> Oh dear.  That's pretty much what we have.  Is that much harder to deal
> with?
> 

No, it's the same functionality. These are both on the other side of the court 
room regularly, hence I took these two companies as an example to emphasize my 
point. However, "novell.com" vs. "sco.com" is actually besides the point.

The thing is... Let's take this hypothetical situation;

Imagine a Hosted Kolab provider. The Hosted Kolab provider gets @novell.com as 
a customer. Another potential customer comes in, @sco.com.

Now, somebody @novell.com can, accidentally or accidentally on purpose, share 
his/her mailbox with this other party that is on the same Hosted Kolab 
infrastructure, basically leaking private corporate information. This 
situation, where cross domain ACLs like that are available, is called 
Discretionary Access Control[1].

In your situation, "3 colleges under the same roof", discretionary access 
control does not create a security risk. The same goes for "two or more 
entities that live in different domain name spaces but are actually as 
friendly as two or more departments within the same entity would be".

With two unrelated businesses on the same infrastructure, however, this is a 
huge security risk -to the extent of, and please mind I Am Not A Lawyer, 
"corporate espionage is illegal by law", "legal liability in case of willful 
misconduct", or whatever is the appropriate term, and possibly inherent legal 
liability for a Hosted Kolab provider -let's not go there.

Besides these potential consequences, a direct consequence of such a situation 
would be that the Hosted Kolab provider won't get any new customers and would 
lose existing customers as soon as any of these customers realize that, 
potentially, other customers can access their data.

This doesn't even have to be on a "multinational enterprise" scale. Two city 
governments could be considered competitors, or two carpenters in two 
different parts of the world -"What's his marketing strategy like?". Most 
significantly however is also the most visible feature of cross domain ACLs, 
the "list of users you can authorize". This one provides a huge information 
base somebody performing a reconnaissance attack can only dream of; all the 
valid user names for a complete environment are at your disposal.

The answer to such security risk would be Mandatory Access Control[2], in 
which case, and I'm paraphrasing, the infrastructure administrator can 
configure sets of rules to describe in which cases cross domain ACLs are 
allowed.

> > By having a better understanding of what realm and scenarios cross-domain 
acls 
> > would be useful for, I'm hoping to make a patch submitted to upstream just 
a 
> > little more to their liking and solve the potential security risk.
> 
> While I suppose subdomains do seem the more logical approach, I don't
> imagine we're the only ones spanning an organisation across multiple
> domains.
> 
> Is this a lot more awkward?
> 

Don't worry, it's not; You have a completely normal use-case scenario here. 
It's merely a tiny little bit different from what I had mentioned as examples; 
the point was that foo.domain.tld could be matched to bar.domain.tld by the 
existence of common denominator "domain.tld"; they are in the same upper-level 
domain name space. The other example listed a company that has company.tld1 
for one country it operates in and company.tld2 for another country. Your 
situation is much the same to the latter example.

Kind regards,

[1] http://en.wikipedia.org/wiki/Discretionary_access_control
[2] http://en.wikipedia.org/wiki/Mandatory_access_control

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08