[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