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 mall...@example.org just adding a sieve rule to forward a copy of
everything to j...@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/tr...@example.org isn't RFC
compliant, but user/j...@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/j...@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
