[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] What's to be Done



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.



--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk