A guide to relatively secure email

General Discussion
#1

Continuing the discussion from [qubes-users] Has anyone had a qube compromised?:

Folks! :slight_smile:

Posts like this can’t be just allowed to pass by like it’s nothing.

It would take most of us six months of blundering to try and recreate this email setup, and even then we wouldn’t have certainty in it’s operation.

Unman has outlined a guide to a secure email system that a couple of skilled people can follow.

We need a guide that can be followed by people just below that skill level.

…and a guide for people the skill level below that.

I don’t have the skills to write the guide but can certainly edit, format or complete it properly. I’m sure there’s no shortage of people on this forum that would do that.

Is this possible? It’s great that people can use email somewhat securely. I sure would like to use email again.

2 Likes
#2

I have a somewhat more detailed note on split-mutt in my notes
I guess it could be extended to any offline mail reader.

2 Likes
#3

This is a very cool setup @unman. I am struggling however to say why it would be more secure than a (minimal) qube with firewall rules that only allow the pop/imap/smtp server(s).

Let me be more precise in what I am trying to compare:

a) your offline, 3 qube, qrexec, mutt setup
b) my minimal qube with only thunderbird and firewall to only my mail server

So one would receive a malicious email with a successful exploit achieving code execution, that code could then attempt to exfiltrate information by sending another email only – right? All other paths out are cut off. The only thing I can think of is the “All DNS requests and ICMP (pings) will be allowed” disclaimer in the firewall panel.

As for sending the information by email, that would work with your setup too, or do you have a manual review/allow before sending/receiving? (that’d be really cool)

1 Like
#4

I used to do the Thunderbird/firewall rule setup at work (and to some degree at home) before I retired, and if my memory serves me correctly thunderbird was hanging for a while while attempting to verify/update plug-ins which was a pain. These attempted accesses had to timeout first before I could retrieve my mail.

I also had one work specific authentication DNS issue with a third party software that never seemed to use the same name/address so I could not just set-and-forget a firewall rule for that. I can’t go into details on that issue, but it was a real pain in the ass for me. What I wound up doing was setting up a process to monitor ICMP access denied comming back from sysfirewall so that I could make the required adjustments and complete the login process.

#5

This seems great. It’s beyond me however.

Would it be possible for a power user to do a screen recording of the entire process from beginning to end?

Something like that would be a great help in giving an average user some certainty in an email setup.

Would it be a kind of “killer app” for qubes? “Install Qubes, then follow this video. Now you’ve got reasonably secure email”

1 Like
#6

I do use custom rules to not allow these: depending on your mail
servers you may not be able to do this.

There is a manual review before syncing to the poster qube, and also a
review there before sending - cool indeed.

More importantly, exfiltration via SMTP does not usually use the user
account - that covert mechanism is blocked here, since exfiltration would
have to cross the qrexec channel and then execute some SMTP process on
the poster. Since that is a disposable, that would be somewhat difficult
to keep running.
It is also possible to restrict outbound traffic from the poster to the
SMTP servers, and to traffic from the msmtpqueue process.

On a more general point, the standard system is persistent and has a
single netvm - if you separate these functions, the fetcher and poster
are disposables, and can be easily routed through separate netvms,
if needed.
Another point I have not emphasized is that you can use a number of
fetchers and posters to cover different accounts, but accumulate the
mail in the same mail reader.

3 Likes
#7

From what I’m able to understand this seems like an extremely well thought out email setup.

Could it be made a priority to write guides, for various skill levels, to recreate and verify this setup?

1 Like
#8

Hi @qube_bert:

Could it be made a priority to write guides, for various skill levels, to recreate and verify this setup?

I agree with you that this is an awesome setup, but please realize that @unman and many others that would have the skills to create such a guide have currently their hands full getting R4.1 out of the door.

If there are community members who have setups like this and could start a draft, I’d be happy to test and edit. This would make it easier for someone like @unman to review the result and give feedback instead of having to create something from scratch.

3 Likes
#9

Hi Sven, thanks for the reply.

What do you think of my concept for writing guides in the OP.

Unman wrote a guide that a few skilled people can follow.

Unman is too busy to write a more detailed guide less skilled people can follow.

The solution is that someone who can understand Unman’s guide, someone less busy, can expand on the guide so that people on the next step of the ladder below can understand and follow it…

…and then someone on the next step of the ladder below, who can now follow the expanded guide, expands a little further so that people on the next step below can understand and follow it…

…and so on…

So, we end up with 4 or 5 guides coming from Unman’s excellent first guide, each more detailed than the last, and maybe I can follow number 5 and write a guide for people on the step of the ladder below me.

What do you think of this concept Sven?

“Install Qubes and follow this detailed guide for secure email” seems like a very attractive selling point.

#10

What do you think of my concept

I don’t think multiple guides are needed, just one detailed one … for R4.1

2 Likes
#11

The example of this concept working is here: Android-x86 'no hard-drive detected' - #16 by GateOfRanre.

Core developers have not enough time to write one detailed guide for everything. I think the idea of short guides is a good one (but they should be explicitly labeled as such).

#12

Great thread, really want to get android installed here too.

Honestly, I’d love to take some time off from survival, pursue some self directed learning, and piece together an intricate secure email system from the notes of core developers.*

A 4-skill-level guide seems much more efficient though. If someone gets stuck they can look at the page written for people one skill level lower. Or even look at the page written for people one skill level above.

Having access to the same configuration guide, but written for 4 different skill levels, would be extremely educational imo.

The configuration guides could be community generated from the initial notes of the core developers. There won’t be any shortage of volunteers to edit, format and proofread imo.

  • No criticism of the developers btw, they’re busy pushing the boundaries.

edit: As mentioned in a previous post, is there any reason why a power user couldn’t screenRecord and narrate the installation procedure of something like Unman’s email system?

2 Likes
#13

I would like to see @unman 's email setup working in a video in all its glory. That would be cool.

#14

trying out @unman’s approach on Qubes R4.1rc2, with debian-11-minimal template.

using the sshfs approach, and here GitHub - unman/qubes-sync: Simple syncin between qubes over qrexec I stumble on some problems:

$ sudo systemctl enable qubes-ssh-forwarder.socket
Failed to start qubes-ssh-forwarder.socket: Unit qubes-ssh-forwarder.socket has a bad unit file setting.
See system logs and ‘systemctl status qubes-ssh-forwarder.socket’ for details.

$ sudo systemctl status qubes-ssh-forwarder.socket
a qubes-ssh-forwarder.socket
loaded: bad-setting (Reason: unit qubes-ssh-forwarder.socket has a bad unit file setting.)
Active: inactive (dead)
Triggers: a qubes-ssh-forwarder.service <= the ‘a’ has a hat on it

day_time mail-receiver systemd[1]: /lib/systemd/system/qubes-ssh-forwarder.socket:number: Assignment out of section. Ignoring.

(with number going up and up into the thousands now…)

Looking at the file qubes-ssh-forwarder.socket I read:

...
          <td id="LC10" class="blob-code blob-code-inner js-file-line">[Install]</td>
        </tr>
        <tr>
          <td id="L11" class="blob-num js-line-number js-code-nav-line-number" data-line-number="11"></td>
          <td id="LC11" class="blob-code blob-code-inner js-file-line">WantedBy=multi-user.target</td>
        </tr>
  </table>
</div>
...

I read somewhere that someone else had the same error message but with him the problem was that [INSTALL] was in all capitals, but in the file I have it’s not.

Anyone knows what I’m doing wrong?

Thanks.
A point of attention within an infinite state of consciousness having an experience
p.s. keeping notes as a go to share if/when able to get it working

#15

Disclaimer: I merely skimmed this topic and cannot help with anything specific, but while reading the forum I found your post and recognized your problem, because I have often done the same in the past.

Your socket file contains HTML code. This cannot be understood by systemd.
When downloading /copying stuff from GitHub, make sure you download the raw file (download the whole repository via git, via the “download as zip” function, download a single file by clicking the “View raw” option, or copy-paste just the specific file content you are interested in.

I any way, do not save a file via the “Save as” menu in your browser and do not point a cli downloader such as wget or curl to the rendered version of the file you are interested in.

#16

Thank you @phl
I just came to the same conclusion and feel so stupid! LOL
Note to self: don’t use wget to fetch something from github :-s

#17

Well you can, you just have to use the raw URL ;).

2 Likes