[Kolab-devel] setting allowcrossdomainacls yes

[Gunnar Wrobel]

Hi Jeroen,

a belated response but I wanted to test this new feature myself before  
answering.

Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

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

While I agree to everything you said concerning what you refer to as  
DAC I think that the risk you describe here is not given. There is no  
"list of users that can authorize" - at least if are denying such  
access in the Kolab LDAP tree which is not the default. But I assumed  
that you were referring to the cyrus side of things.

It is also not possible to guess the user names. Assume you are User  
A, have address "a at domain1.org" and you'd like to know if a User B is  
a member of "domain2.org". Then the fact that you can give  
"b at domain2.org" access to your INBOX does not tell you anyting. You  
could add "thisuserdoesnotexist at domain2.org" and would succeed. Adding  
"b at thisdomaindoesnotexist.org" would also succeed. There is no check  
against the user database or the available domains involved.

I'm just adding this to avoid the impression that we voluntarily add  
security holes into the Kolab server :)

As you already discussed with Gavin: DAC is possible and we allow to  
activate this if people are certain they want this. So I would hope it  
is kind of a controllable security risk.

Cheers,

Gunnar

>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.