POLL: per-domain shared folder/sieve/etc

Mon Nov 3 06:52:02 EST 2014

On 2014-11-01 21:29, Bron Gondwana wrote:
> We already have one at FastMail to stop users setting an 'anyone' ACL.
> 

I think this may already be in upstream, unless you're talking about a 
different implementation/solution?

   http://git.cyrusimap.org/cyrus-imapd/tree/lib/imapoptions#n179

>> > This is all, obviously, Cyrus 3.0 stuff.
>> >
>> 
>> In the multi-domain environments we typically run, while sharing 
>> between
>> domains is indeed an often requested feature, we love the inability to
>> share cross-realm -- preventing accidentally sharing your @company.com
>> content with @competitor.com people.
> 
> Yes, that's pretty dangerous, isn't it.
> 
>> If the new way of doing things is to allow cross-realm sharing, I 
>> would
>> like to ensure some sort mandatory access policy is in place, where 
>> one
>> has to specify @something can in fact share with @else.
> 
> This is tricky, particularly for FastMail where multiple companies can
> have addresses in the shared domains (e.g. fastmail.com) as well.
> 
> It sounds like the right general approach is to allow an external
> daemon to be queried for policy responses.
> 

I suppose the level of complexity depends on the level of flexibility / 
features required.

Suppose that the default is to not have any realm be allowed to use any 
other realm (no other realm's mailboxes are visible, no ACL subject 
identifiers validate). This, I would say, represents the current 
situation most accurately.

Suppose a list of source realms (the authenticated user is in this 
realm) is used as a lookup key, and for any other realm that realm must 
have presence in the lookup value) -- admittedly a very simplistic view:

company.com: subsidiary.com partner.com
subsidiary.com: company.com
partner.com: company.com competitor.com
competitor.com: partner.com

Suppose this means that @company.com people (source, lookup key) can 
share @company.com mailboxes (source, lookup key, must match logged in 
account?) with @subsidiary.com and with @partner.com ACL subject 
identifiers.

Suppose this means @partner.com (target lookup value) can therefore see 
@company.com mailboxes -- but cannot share with @company.com because of 
the first rule, but because of the third rule.

I do not suppose there is any use-case to nesting such rules to the tune 
to, in the above list, allow subsidiary to partner descending to company 
authorizations (or any other way).

I suppose in the case of FastMail, you would list fastmail.com as a 
lookup key and perhaps use a regular expression .* to ensure 
@fastmail.com mailboxes are visible to all other realms?

> Of course, to a certain degree this is trying to make a technical
> solution to a human problem.  If it's that vital that they can't see
> each other, they should be on separate Cyrus instances at the very
> least, if not entirely separate infrastructure.  There's nothing to
> stop mallory at example.org just adding a sieve rule to forward a copy of
> everything to john at company.com, or handing over credentials, or any
> number of things.
> 

I agree with the general sentiment, but disagree with such separation on 
the infrastructure level being that kind of a must (for that level of 
vital).

There are other considerations that could require an organization to 
have infrastructure isolated from a multi-customer "hosted" environment, 
but such are in the gut-feeling-more-so-than-technical-literacy, 
compliance and telco regulatory domains.

While "to share or not" is certainly a social problem, and "to enable 
sharing or not" probably is so too, "to allow sharing or not" is 
definitely a more technical one if the implementation thereof leaves 
behind a Free-for-All.

For Sieve rules forwarding content, cross-realm ACLs are rather 
irrelevant. One could (define to) forward content using Sieve 
regardless, unless Cyrus IMAP's Sieve implementation is extended to 
allow a similar level of access control.

The current methodology to prevent this from happening lays in limiting 
the user interfaces, not including Sieve extensions, MTA configuration 
and Data-Loss Prevention systems -- neither of which are helped or 
negated by introducing cross-realm ACLs, and neither of which requires a 
given customer to run off of completely separate infrastructure.

Should sharing across domains be allowed, but without mandatory access 
control, however, then you move Cyrus IMAP from the "perfect for hosted 
environments with multiple customers" universe to the "it's such a 
Free-for-All you require separate infrastructure for each customer".

>> On 2014-10-24 02:59, Bron Gondwana wrote:
>> > No, the per-user namespace is still fine - users can still share with
>> > other users in their own domain - just currently it is technically
>> > impossible to share with users in other domains right now - because the
>> > mailbox naming is not RFC compliant, so it's not compatible with real
>> > IMAP client, only with Cyrus management tools.
>> >
>> 
>> You mentioned in another post (quote above) that the current naming of
>> mailboxes is not necessarily RFC-compliant, and that only the Cyrus
>> tooling is compatible.
>> 
>> I may be misunderstanding what this means, because only an 
>> administrator
>> without a realm (as part of its login username) is currently able to
>> view lists of mailboxes across realms -- bear with me while I 
>> transcribe
>> from the top of my head:
> 
> Yes, but the administrator can't use RFC compliant tooling to do it,
> because the LIST response is bogus.
> 

I don't understand what RFC compliant tools you are referring to, that 
have a reason to be used by an administrator (i.e. not webmail and not a 
desktop client).

I also don't understand what part of RFC compliance you are referring 
to, when you say that the current naming is not RFC compliant. I suppose 
you mean the current naming of user/jane/Trash at example.org isn't RFC 
compliant, but user/jane at example.org/Trash would be?

If so, I suppose this makes the RFC compliance concern a side-effect 
specific to enabling any sort of cross-realm sharing in the first place, 
right? ;-)

> So I am considering an option, stripsamedomain or something, which
> means that jane still sees "Other Users/max", but could also see
> "Other Users/john at company.com" if allowed.
> 

I do not suppose that, should cross-realm sharing be allowed, and be 
subject to policy (mandatory access control), I would necessarily desire 
an option "stripsamedomain" at all -- if it's all the same to you as 
well, I would drop such option.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
w: http://www.kolabsys.com

pgp: 9342 BF08