[tor-talk] What's to be Done

[bancfc at openmailbox.org]

Fantastic talks by Jacob as always, he hammers home many major system 
hardening ideas. I summarized the points in the talks and will build on 
them with more ideas and information.

I encourage everyone to see the DebConf talks by all means:

http://gemmei.acc.umu.se/pub/debian-meetings/2015/debconf15/Citizenfour_Q_A_Session.webm

http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/What_is_to_be_done_Reflections_on_Free_Software_Usage.webm

***

Debian Hardening topics covered:
* Disabling Avahi and Samba NFS by default
* Packaging grsecurity/PaX, Pond, xmpp-client, Tor Browser, Tor-launcher 
and pluggable transports - work currently being done on Tor related 
packages as of 2015
* Adoption of Subgraph Oz sandboxing framework
* Cleaning vulnerable legacy networking protocols out of the Debian 
kernel
* Distribution of Tor in a base Debian distro
* Giving a sshd onion service as an install time option
* Encryption of system as default on install time
* Address Sanitizer and compiler time hardening of packages
* Adoption of new rootless, type safe DHCP daemon written by him and Dan 
Bernstein
* Adoption of tlsdate or alternative to unsafe NTP
* Gnuk libre hardware keycard adoption
* Encrypting APT connections to prevent package metadata leaks and make 
exploiting problems in APT harder

Other topics:
* Blacklisting mouse jigglers in systemd
* Trust problems with proprietary hardware
* NSA Nightstand program WiFi stack injector
* Reversing targeted malware with Hercules by running Irssi IRC client 
honeypot on a grsecurity enabled environment inside a s390 emulated 
system all running on the libre Milkymist FGPA
* Non-adversarial forensics to verify systems integrity and compromise 
attempts
* Ways to verify system firmware compromise thru dumping images and 
archiving them
* Source code review in addition to reproducible builds to detect 
maintainer coercion situations

***

Thoughts:

* grsecurity has its own superior Mandatory Access Control framework 
called RBAC. RBAC has advanced system behavior learning to generate 
complex policies on the fly. Writing policies is similar to the 
simplicity of Apparmor vs the absurd difficulty of SELinux

* LSM has many problems and SELinux in particular actually weakens a 
system in some ways that it wouldn't be without it. Its safe to say 
"With security like this who needs backdoors?"

* Wayland should address the security nightmare that is X but until then 
there is work being done by RedHat to make X run rootless

* The maintainer coercion problem can be avoided if they are 
pseudonymous Tor users. With reproducible builds the problem of tainted 
binaries should be over or at least they won't be deniable. Should 
malicious source code ever slip in it will be traceable in the public 
record with code audits

* Reproducible builds are great and a step further is to have Debian and 
systemd run deterministically so that the order folders are accessed and 
services started during boot up is identical. Should make verification 
and non-adversarial forensics easier to avoid this:
http://askubuntu.com/questions/618105/systemd-non-determinism-early-on-in-boot-from-squashfs

* Firefox is in a bad place from a security perspective. The rust based 
Servo engine is far away. In the long term an equally dangerous threat 
to Firefox's viability is Mozilla adopting  policies and directions that 
endanger its freedom:
** signed addons is a great step to ensuring add on integrity but 
Mozilla disallowing custom user generated keys is a step back for user 
freedom and being able to consensually run addons Mozilla doesn't 
approve of.
** adoption of the watered down WebExtensions API and deprecation of the 
XUL plugin system is huge setback for addon power and flexibility. It 
will impact TBB addons like Torbutton. This decision was made in favor 
of making Chrome addons fully compatible across both platforms without 
considering what will be sacrificed. As Firefox becomes a Chorme clone 
the Tor Project will run into the design limitations they avoided on the 
first place by staying away from Chromium.

* Metadata leaks and exploitation of APT bugs during system updates 
could be addressed best by having Debian support Onion Services for 
their update servers and push for mirrors adopting it. AFAICT there was 
a brief experiment by the guardianproject's Hans-Christoph but when he 
tried encouraging Debian mirror admins to run behind Tor he got a lot of 
push back. apt-transport-tor might need changes to support onion mirror 
URLs.

* Blacklisting mouse jigglers is a great idea however a better way is to 
configure the system to panic immediately and shutdown if  a USB device 
is plugged in when you don't expect one to be. A package already exists 
that does this called usbkill:
https://github.com/hephaest0s/usbkill
This can be packaged in Debian and further integrated into a panicd 
daemon that can immediately shutdown a LUKS encrypted system if a 
certain key is pressed similar to what Truecrypt did. grsecurity has an 
option to disable USB devices too.

* There is a unique proof of concept for Linux that allows a LUKS 
encrypted system to safely standby without leaving master encryption 
keys in RAM. I would love to see this developed more and enabled by 
default in Debian:
https://github.com/jonasmalacofilho/ubuntu-luks-suspend

* tlsdate is a good start but to solve the time source problem I am 
looking towards the Tor network. An accurate system time is very 
important for security:

https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html

  The Tor network is already considering a secure multiparty computation 
proposal to generate entropy for directory authorities. I can see a 
similar situation with broadcasting a safe system time via the Tor 
protocol agreed to by relays running atomic clocks as a future solution. 
Alternatively the organizations running Time servers could be nudged to 
run http Onion Services for HTTP/TCP based time daemons to set time from 
them like Tails htpdate and Whonix sdwdate, the latter already uses 
multiple sources of friendly Onion Services as clock sources. One day 
Debian could ship with a Tor based time daemon.