[Kolab-devel] setting allowcrossdomainacls yes
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Wed Sep 1 14:41:33 CEST 2010
Gavin McCullagh wrote:
> 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
> > 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.
> > 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
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.
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, in
which case, and I'm paraphrasing, the infrastructure administrator can
configure sets of rules to describe in which cases cross domain ACLs are
> > By having a better understanding of what realm and scenarios cross-domain
> > would be useful for, I'm hoping to make a patch submitted to upstream just
> > 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
> 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.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
pgp: 9342 BF08
More information about the devel