[tor-commits] [tlsdate/debian-master] Add first draft of notes on how we harden and how we plan to evolve

[ioerror at torproject.org]

commit b53ea90001a5a89c6839bdf220e857a3e936ef73
Author: Jacob Appelbaum <jacob at appelbaum.net>
Date:   Thu Apr 18 23:41:35 2013 -0700

    Add first draft of notes on how we harden and how we plan to evolve
---
 HARDENING |   59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/HARDENING b/HARDENING
new file mode 100644
index 0000000..479b355
--- /dev/null
+++ b/HARDENING
@@ -0,0 +1,59 @@
+Platforms offer varying security features; we'd like to support the best.
+
+This is a document that notes which security hardening we have implemented and
+which things we'd like to see implemented for various platforms. We
+specifically address exploitation mitigation and containment; security issues
+such as x509 certification validation are not addressed here. Patches,
+suggestions and improvements are welcome! We always want the strongest set of
+options by default on each supported platform.
+
+On all platforms we attempt to support available compiler hardening and linking
+options. Please do not disable these options. Additional compiler and linker
+hardening options are welcome and the current options are implemented in the
+following file:
+
+  configure.ac
+
+On all platforms, we attempt to switch from the administrative user to an
+unimportant role account which shares data with no other processes. If we start
+as any user other than an administrative user, we will likely be unable to
+switch to our normal unprivileged account. These users are defined at
+`configure` time.
+
+In addition to the above hardening options, we have tried to extend our
+hardening when the platform supports it. Each additional security measure that
+we take is documented as well as planned or desired improvements.
+
+We do not currently support or set ulimits, we should do so where possible.
+
+On Debian Gnu/Linux platforms, we ship with a minimal AppArmor profile, see
+the policy for details:
+
+  apparmor-profile
+
+We'd like to have an SELinux policy specifically for tlsdate.
+We'd like to support capability dropping with libcap or libcap-ng.
+We'd like to support libseccomp2 filters.
+Other kernel hardening suggestions are welcome.
+
+On ChromeOS we use minijail and seccomp filters, see the following policies for
+details:
+
+  tlsdate-seccomp-amd64.policy
+  tlsdate-seccomp-arm.policy
+  tlsdate-seccomp-x86.policy
+
+These are enabled by default in ChromeOS.
+
+On FreeBSD, we'd like to support jails, chroot, and Capsicum.
+
+On OpenBSD, we'd like to support chroot and systrace.
+
+On NetBSD and DragonFly BSD, we'd like to chroot.
+
+On Mac OS X, we'd like to support chroot and seatbelt.
+
+On Plan9, we'd like to chroot.
+
+On other platforms, we'll try to run correctly with the understanding that any
+bug is likely a much more serious problem.