Tails Features/Ideas

[HulaHoop]

https://blog.torproject.org/blog/tails-24-out

• Remove the preconfigured #tails IRC channel. Join us on XMPP instead!
  ** Then configure your preferred instant messaging client, for example Pidgin, which runs on Windows, GNU/Linux, and Mac OS X, to connect to:

  server: conference.riseup.net
  room: tails
  Use TLS/SSL to connect!

(Using Pidgin is terrible advice but maybe the riseup xmpp service is a good idea?)

• Use secure HKPS OpenPGP key server in Enigmail.

(I know our keyservers point to a HS, does this apply to Enigmail too?)

• Harden our firewall by rejecting RELATED packets and restricting Tor to only send NEW TCP syn packets. (#11391)

• Harden our kernel by:

  Setting various security-related kernel options: slab_nomerge slub_debug=FZ mce=0 vsyscall=none. (#11143)
  Removing the .map files of the kernel. (#10951)

• Enable Packetization Layer Path MTU Discovery for IPv4. This should make the connections to obfs4 Tor bridges more reliable. (#9268)

[Patrick]

Remove the preconfigured #tails IRC channel. Join us on XMPP instead!** Then configure your preferred instant messaging client, for example Pidgin, which runs on Windows, GNU/Linux, and Mac OS X, to connect to:

server: conference.riseup.net
room: tails
Use TLS/SSL to connect!

(Using Pidgin is terrible advice but maybe the riseup xmpp service is a good idea?)

If someone is up to host and run it, go ahead. I am not great with instant messengers. Too disruptive. I personally do it only on request to speak about specific topics. Not as a general hangout.

Use secure HKPS OpenPGP key server in Enigmail.

(I know our keyservers point to a HS, does this apply to Enigmail too?)

Yes. Can verify by checking icedove enigmail keyserver settings.

related:
https://github.com/Whonix/anon-gpg-tweaks/blob/master/etc/skel/.gnupg/gpg.conf

Harden our firewall by rejecting RELATED packets and restricting Tor to only send NEW TCP syn packets. (#11391)

RELATED,ESTABLISHED -> ESTABLISHED was done for Whonix 13. Ticket:
https://phabricator.whonix.org/T28

They haven’t explained how restricting Tor, what restricting Tor to only send NEW TCP syn packets should be good for.

Harden our kernel by:
Setting various security-related kernel options: slab_nomerge slub_debug=FZ mce=0 vsyscall=none. (#11143)
Removing the .map files of the kernel. (#10951)

Something worthwhile for https://www.whonix.org/wiki/Advanced_Security_Guide.

Why isn’t this done upstream in Debian? We ought to figure that out before changing these things in Whonix.

related:
Qubes mailing list discussion: linux kernel hardening
https://groups.google.com/forum/#!topic/qubes-devel/LK2EPYOlczo

Enable Packetization Layer Path MTU Discovery for IPv4. This should make the connections to obfs4 Tor bridges more reliable. (#9268)

I don’t think we have this problem in Whonix. If anything, this only matters for Whonix with physical isolation without virtualized Whonix-Gateway.

[HulaHoop]

Very interesting info on haveged

haveged relies on the RDTSC instruction, that apparently is useless in some virtualized environments. Also, the quality of random numbers output by HAVEGE is unclear, and the topic of many discussions.

https://tails.boum.org/contribute/design/random/#rngd

At least on KVM its not useful but we don’t need it anyhow since there is a dedicated rng device.

rdtsc or any tsc counter provides very accurate clock tick information so better to block.

[Patrick]

kaslr

https://labs.riseup.net/code/projects/tails/repository/revisions/c48b9f65828b664c79eeb6fb41c7dc9aebb3ea31/diff

---

related:

Issue: Kernel hardening - change default options

[HulaHoop]

Linux kASLR is known as not being particularly strong, but one has to start somewhere.

Not an understatement. Though I thought vanilla kernels in Debian enabled it but doesn’t seem so.