Qubes and Email/PIM (Was: Re: [qubes-users] Re: Security questions (templates and kde)

[799]

Hello,

Am 06.03.2018 10:04 nachm. schrieb "Steve Coleman" 

Because the SMTP infrastructure was not designed with compartmentalization in mind, and I only get my one email account to work with, this single "email" VM is highly isolated. It gets its own software locked down configuration and is firewalled with a default-deny network policy. The only services that this VM can get to on the network is the required SMTP services, network authentication, and the necessary  signing key management.  No internal websites, no external sites, only the email App runs here. Well, Ok, the calendar too. Anyway, there should be no "phoning home" from here, other than through per use 2fa outbound email. Should any rouge malware be received, all attachments are first scanned and "tested" in a DVM instance before being separated and pushed across to the appropriate project VM for storage management. All project related historical emails are then migrated to an off-line but searchable storage by project. This specialized email VM essentially sorts, filters, prioritizes, and bins any incoming data/mail for easy processing.

Do you mind writing some more details as I am interested how other people solve the email problem.

Are you really separating email in different AppVMs?

Even when you said, that the VM can only connect per SMTP I assume that you are not separating IMAP (incoming) and SMTP (outgoing) into two two VMs and then moving emails from the incoming mail VM to the offline mail VM?

You have one VM which makes both IMAP and SMTP correct?

Which email/calendar client are you using and how do you move mails to your  offline email VM?

My setup:

Dedicated Email VM with Davmail installed. Davmail connects per OWA to our corporate Microsoft Exchange Server and acts as some kind of gateway to provide local SMTP/IMAP/CardDAV/CalDAV connections.

For emails I am running offlineimap which connects locally to Davmail and downloads all emails and creates a local maildir-repository.

Contacts and calendar entries are downloaded via vdirsyncer.

All content is now locally available in this Email-AppVM and can now also be used offline.

Within this VM I have setup:

For plaintext work:

- neomutt - email client

- khal - calendar

- khard - adressbook

- notmuch - fast search

And as GUI email clients (connecting to the Davmail gateway / not using the maildir-repository)

- Evolution

- Thunderbird

Unfortunately not everything works with the Davmail Gateway:

I can see the exchange Calendar in Thunderbird, but not the calendars of my colleques. If I open a calendar entry I get an error.

On Evolution calendar is working much better as I can open and view the details of an calendar entry, I can create and edit calendar entries - everything is synced per Davmail to our corporate Exchange.

Strangely I can not delete calendar entries in Evolution.

With khal I can also view/edit my  calendar entries in the terminal.

Same for khard with my contacts.

Todo:

1) Check why I can add/edit calendar entries but not delete them

2) optimize handling of attachments that PDFs / Office documents / Weblinks are always opened in a DVM.

I have been able to do this for Thunderbird but not yet for neomutt and Evolution.

3) I'd like to integrate email and calendar into emacs org-mode, which I am more and more using for PIM.

4) lock down EmailAppVM so that it can only access the Microsoft Exchange Mailserver nothing more.

I would do so by running IPtables within the VM with a default incoming/outgoing DROP policy only adding what is absolutely necessary to get mail/contacts/calendar working with the Exchange server

I have also thought about separating email into more AppVMs but the usability trade-off seems to high without gaining that much security.

As the Email AppVM only is used for email/calendar it should have the same security level like our Exchange Server. If it gets compromise it doesn't make a difference what I have setup in Qubes.

[799]

[Steve Coleman]

Glad to hear I'm not the only one paying attention to this particular
attack surface. There is nothing like a wide open 24x7 automated attack
surface to keep you up at nights wondering what web exploits will be
discovered next by the hacker community. Even with layers of security
well before things get to me, I'm still wanting to be extremely diligent
with threat mitigation when it comes to unsolicited email.

On 03/07/18 20:55, 799 wrote:

> Do you mind writing some more details as I am interested how other
> people solve the email problem.
> Are you really separating email in different AppVMs?

I only separate attached documents and move them to the respective
project VMs. The email itself is coming in from IMAP and I have an
elaborate set of macro filters that test the SMTP headers details,
validate, flags their state, and process them by moving them off of IMAP
and into an offline mail storage location. If it doesn't pass my barrage
of sanity tests then I don't even pull it onto my system.

> Even when you said, that the VM can only connect per SMTP I assume that
> you are not separating IMAP (incoming) and SMTP (outgoing) into two two
> VMs and then moving emails from the incoming mail VM to the offline mail VM?

Correct. Everything gets sorted base on work related vs personal
interests (eg. Qubes users forum has its own folder) with work/project
grouped and lower priority which I read when I can find time.

> You have one VM which makes both IMAP and SMTP correct?

Yes. As far as I can see that is the only way other than building some
sort of rpc mail proxy to make a distributed VM email system, and that
might just widen the attack surface. My email VM does nothing but sort
my email and allow me to send outgoing SMTP as well.

My email VM is denied access to the Internet so any links to malware
content will denies rough sites reach-back capability and prevents
drive-by malware installs. I don't see icons or web content and I am
just fine with that.

The qubes Thunderbird/DVM integration works nicely for automatically
opening any untrusted documents for testing, and if the document needs
to be retained I merely copy it to the appropriate VM for processing or
archiving. The base of the email has already been moved off the IMAP
server and into file system storage into sorted folders for searching or
deletion after processing.

My goal is to automate the email processing grunt work and apply a
defense of security validations even before even copying it onto my
machine for processing. I have checks in place that validate which
emails came from what place, and test how it was authenticated and
passed through the IT infrastructure to get to me. A properly
authenticated internal email gets labeled as such.

If anything is different or suspicious it gets flagged as abnormal and
gets a manual inspection to determine the nature of the unexpected
"feature" of that email. External incoming PDF/DOC documents that could
have embedded macros get flagged as suspicious. It could be phishing or
IT changing their processing because of outages, etc. One day I might
look at putting in some basic deep-learning AI into the process stream
to make it even smarter at detecting processing anomalies such as faked
SMTP headers. That's a little too hard for Thunderbird at the moment.

> Which email/calendar client are you using and how do you move mails to
> your  offline email VM?

I have Thunderbird/IMAP with Lightning for calendar, because it works
fairly well for my purposes. I do use Davmail, but only for the calendar
side of things. One issue with calendar is I keep getting told that a
calendar event had changed and it asks whether to discard or send any
way, and that gets annoying. One day I'll take the time to figure out why.

I like that Thunderbird and the Lightning/calendar invites work
together. At one point Thunderbird got an update and lightning stopped
working, to the point that Thunderbird deactivated it. That sucked, so I
used OWA access for a while and just now realized lightning had been
updated so I reinstalled it. That is one problem with my email VM being
off-line, in that Thunderbird can't check for updates automatically.
That is a catch-22, but I still prefer to keep it this way. The less it
can do on the network, more minimal its attack surface.

> My setup:
> Dedicated Email VM with Davmail installed. Davmail connects per OWA to
> our corporate Microsoft Exchange Server and acts as some kind of gateway
> to provide local SMTP/IMAP/CardDAV/CalDAV connections.
> For emails I am running offlineimap which connects locally to Davmail
> and downloads all emails and creates a local maildir-repository.

> Contacts and calendar entries are downloaded via vdirsyncer.

I had not heard of that, thanks. I'll look into that.

> All content is now locally available in this Email-AppVM and can now
> also be used offline.
> Within this VM I have setup:
> For plaintext work:
> - neomutt - email client
> - khal - calendar
> - khard - adressbook
> - notmuch - fast search
>
> And as GUI email clients (connecting to the Davmail gateway / not using
> the maildir-repository)
> - Evolution
> - Thunderbird
>
> Unfortunately not everything works with the Davmail Gateway:
> I can see the exchange Calendar in Thunderbird, but not the calendars of
> my colleques.

Yes, creating a meeting generally requires rdp session to an IT
controlled Windows(tm) VM. Life would be easier if I had my own local
Windows VM for software testing, but they want complete control of that
malware magnet.

> If I open a calendar entry I get an error.
> On Evolution calendar is working much better as I can open and view the
> details of an calendar entry, I can create and edit calendar entries -
> everything is synced per Davmail to our corporate Exchange.
> Strangely I can not delete calendar entries in Evolution.

On lightning I can open, create, modify, and delete, but I do get that
annoying update-anyway-(y/n) prompt when saving it.

> With khal I can also view/edit my  calendar entries in the terminal.
> Same for khard with my contacts.
>
> Todo:
> 1) Check why I can add/edit calendar entries but not delete them
>
> 2) optimize handling of attachments that PDFs / Office documents /
> Weblinks are always opened in a DVM.
> I have been able to do this for Thunderbird but not yet for neomutt and
> Evolution.
>
> 3) I'd like to integrate email and calendar into emacs org-mode, which I
> am more and more using for PIM.
>
> 4) lock down EmailAppVM so that it can only access the Microsoft
> Exchange Mailserver nothing more.

> I would do so by running IPtables within the VM with a default
> incoming/outgoing DROP policy only adding what is absolutely necessary
> to get mail/contacts/calendar working with the Exchange server

Doing it in the email VM won't add much security, because an adversary
could just sudo and phone home. What I did was to set the firewallVM
settings to default deny and then use tcpdump to listen for ICMP
"administratively prohibited" messages coming back from the firewallVM.
I create a script running in dom0 that qvm-run's that session with the
'-p' io returned that creates formatted qvm-firewall permit commands,
and I just cut and paste the ones I want into a dom0 command window if I
want to permit one or two during a training session. Once you have the
core infrastructure mapped during the training session you can set all
that back on the shelf and the emailVM just works, and there are no
leaks out to the internet other than the sending of email. If the SMTP
server was session is momentary and and 2FA used, the the only chance
for exfiltration would be limited to when you are sending email. If you
shorten that window of opportunity then its again raising the bar for
the adversary exfiltrator.

> I have also thought about separating email into more AppVMs but the
> usability trade-off seems to high without gaining that much security.
> As the Email AppVM only is used for email/calendar it should have the
> same security level like our Exchange Server. If it gets compromise it
> doesn't make a difference what I have setup in Qubes.

I don't think it would buy much and would only increase the attack
surface via email. keep it simple :>

Steve

>
> [799]

[Yuraeitha]

I do something similar yeah, although I haven't taken it was far as I'd like to yet, and you guys also bring up some interesting fresh ideas as well that I will follow up on and read later.

I currently have 5 different AppVM's for different mail accounts. But 3 of them are only checked when I'm actively spending time work related to them, which is nice because I don't need to receive those emails when not in that work-mode anyway, so I don't get disturbed.

I've been thinking about the one direction firewall systems too, i.e. only allow in on one AppVM, and only allow out on another AppVM. But man.... it's a lot of AppVM's to do something like that, especially when I already got 5 e-mail AppVM's, it'd essentially double it to 10 AppVM's. But then again, it doesn't cause me issues to have many AppVM's as long as I have drive space, I use XFCE4 launchers to start my AppVM's, and I don't use the Qube Manager anymore anyhow, so a long list of AppVM's won't feel cluttered to me.

The only remaining problem then, would be to have a CPU fast enough to make start of e-mail VM's feel almost like no time wasted, and then enough RAM (for example 8GB is a bit on the low side, too many new laptops are still 8GB as well).

To smooth something like that out though, it'd probably be nice to have a Qubes tools of sorts, to make two AppVM's act similar to how split bitcoin and split GPG works in Qubes;
https://www.qubes-os.org/doc/split-bitcoin/
and
https://www.qubes-os.org/doc/split-gpg/

But it could work without, albeit a bit on the wacky side of things with extra management without a hypothetical Qubes mail tools to make two AppVM's work together here :/

[Yuraeitha]

Perhaps a Qubes script to pull the plug on the mail AppVM could do the trick to push it a notch further? It should be a fairly simply script to make too, probably like 10 lines or so? and it can be kept in dom0, so it's kept away from manipulation too. Then keybind it, and press to toggle connection to that AppVM. Albeit the toggle probably require the script to be a little bit bigger. If using two keybinds though, then it's even more simple, and more easy not to do a mistake on the toggle too. Could something like that improve it though?

Having all mail in a single VM without loosing security seems like an interesting option, it'd certainly make life a bit easier on Qubes.